refs FOO-2720
refs DE-1022
Currently, translations are compiled on a per-scope level. The primary problem by doing this is that each generated scope file contains the translations for all languages, leading users to needing to download translations for languages they will never use.
Instead, we now generate a single translations file per language. This file is loaded and cached by the browser at the beginning of page load.
[change-merged]
[build-registry-path=jenkins/canvas-lms/de-1022]
Change-Id: I64b0d054b04e3d81bb7263650481d1d3fe9a4868
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284285
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2720
flag = none
Short version: the "_core_en.js" file is no longer loaded in production
as its contents have been merged (there) with the super "core.js" file,
which is targeted for removal later in this series.
Change-Id: I05eb76a2f1cac12b4ab953bad0ca5a49b6ffd37b
---
The problem as I understand it: there are certain phrases that are
marked as "core" because they are used by shared/logic code like
DateTime formatters and are pre-defined in config/locales.yml. These
phrases were being supplied in two distinct files:
- _core_en.js, which includes only the phrases for the "en" language
- _core.js, which includes the phrases for the rest of the supported
locales
_core_en was split because it was deemed necessary to be loaded always,
regardless of the active locale, and that is - as it appears to me, at
least - because some code attempts to look up those phrases at the
time their modules are evaluated. This patch corrects those modules to
defer their lookups until the point where the translations are used,
and when the translations have become available -- just like the rest of
the codebase does.
But if this is true, this begs the question, how come those modules
weren't presenting bugs by using translations for "en" and not for the
target locale? My thinking is that it is only coincidental that they
weren't: should _any_ module that uses I18n be evaluated _before_ any of
those modules, the Webpack plugin will have already loaded the "core"
file, which includes the translations for those phrases in the target
locale. _core_en may not have been loaded by then, but that doesn't
matter because the resolver is gonna look for what's in _core first when
it's available, and it is.
---
What happens in this patch is a slight change to prepare for the full
removal of both _core and _core_en: _core_en is now loaded only in
builds that don't load actual translations because we need the default
values that that file provides. The alternative would've been to go to
each call-site that looks up the phrases provided in _core_en and have
them supply default values, but it's untenable at this point.
This is the list of call-sites and the phrases they look up:
ui/features/calendar/jquery/index.js: time.formats.tiny_on_the_hour
ui/features/quiz_statistics/util/parse_number.js: number.format.delimiter
ui/features/quiz_statistics/util/parse_number.js: number.format.separator
ui/shared/day-substitution/backbone/views/DaySubstitutionView.coffee: date.day_names
ui/shared/syllabus/jquery/calendar_move.js: date.month_names
ui/shared/datetime/jquery/DatetimeField.js: date.formats.medium
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_month_names
ui/shared/datetime/jquery/DatetimeField.js: date.day_names
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_day_names
ui/shared/datetime/jquery/DatetimeField.js: date.datepicker.column_headings
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.hour
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.minute
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.am_pm
ui/shared/handlebars-helpers/dateSelect.js: date.order
ui/shared/handlebars-helpers/dateSelect.js: date.*
ui/shared/i18n/i18nObj.js: number.format
ui/shared/i18n/numberHelper.js: number.format.delimiter
ui/shared/i18n/numberHelper.js: number.format.separator
dateSelect.js is the gnarly one because it seems to be passing through
everything under date.* to God knows who.
The list above was generated with a command similar to this:
grep -rnP "I18n.(t|lookup)\(['\"](date|datetime|number|support|time)\S" ui
---
~ test plan ~
~~~~ ~~~~
- you can still activate a different locale and use something like the
datepicker to normal effect
[change-merged]
[build-registry-path=jenkins/canvas-lms/foo-2720-01]
Change-Id: Ifd5d2d888edc9b89a9930824f2c55fd9c275b03f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284102
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2720
flag = none
Short version: the "_core_en.js" file is no longer loaded in production
as its contents have been merged (there) with the super "core.js" file,
which is targeted for removal later in this series.
Change-Id: If97f75066aea32dd74c3899db7aec8fcf4cd93db
---
The problem as I understand it: there are certain phrases that are
marked as "core" because they are used by shared/logic code like
DateTime formatters and are pre-defined in config/locales.yml. These
phrases were being supplied in two distinct files:
- _core_en.js, which includes only the phrases for the "en" language
- _core.js, which includes the phrases for the rest of the supported
locales
_core_en was split because it was deemed necessary to be loaded always,
regardless of the active locale, and that is - as it appears to me, at
least - because some code attempts to look up those phrases at the
time their modules are evaluated. This patch corrects those modules to
defer their lookups until the point where the translations are used,
and when the translations have become available -- just like the rest of
the codebase does.
But if this is true, this begs the question, how come those modules
weren't presenting bugs by using translations for "en" and not for the
target locale? My thinking is that it is only coincidental that they
weren't: should _any_ module that uses I18n be evaluated _before_ any of
those modules, the Webpack plugin will have already loaded the "core"
file, which includes the translations for those phrases in the target
locale. _core_en may not have been loaded by then, but that doesn't
matter because the resolver is gonna look for what's in _core first when
it's available, and it is.
---
What happens in this patch is a slight change to prepare for the full
removal of both _core and _core_en: _core_en is now loaded only in
builds that don't load actual translations because we need the default
values that that file provides. The alternative would've been to go to
each call-site that looks up the phrases provided in _core_en and have
them supply default values, but it's untenable at this point.
This is the list of call-sites and the phrases they look up:
ui/features/calendar/jquery/index.js: time.formats.tiny_on_the_hour
ui/features/quiz_statistics/util/parse_number.js: number.format.delimiter
ui/features/quiz_statistics/util/parse_number.js: number.format.separator
ui/shared/day-substitution/backbone/views/DaySubstitutionView.coffee: date.day_names
ui/shared/syllabus/jquery/calendar_move.js: date.month_names
ui/shared/datetime/jquery/DatetimeField.js: date.formats.medium
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_month_names
ui/shared/datetime/jquery/DatetimeField.js: date.day_names
ui/shared/datetime/jquery/DatetimeField.js: date.abbr_day_names
ui/shared/datetime/jquery/DatetimeField.js: date.datepicker.column_headings
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.hour
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.minute
ui/shared/datetime/react/components/render-datepicker-time.js: datepicker.titles.am_pm
ui/shared/handlebars-helpers/dateSelect.js: date.order
ui/shared/handlebars-helpers/dateSelect.js: date.*
ui/shared/i18n/i18nObj.js: number.format
ui/shared/i18n/numberHelper.js: number.format.delimiter
ui/shared/i18n/numberHelper.js: number.format.separator
dateSelect.js is the gnarly one because it seems to be passing through
everything under date.* to God knows who.
The list above was generated with a command similar to this:
grep -rnP "I18n.(t|lookup)\(['\"](date|datetime|number|support|time)\S" ui
---
~ test plan ~
~~~~ ~~~~
- you can still activate a different locale and use something like the
datepicker to normal effect
Change-Id: I12ff180da35dcf916137818ab91296dab469f3c0
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284582
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Aaron Ogata <aogata@instructure.com>
QA-Review: Aaron Ogata <aogata@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
refs FOO-2697
flag = none
webpack config for karma is also independent now and no longer tied to
the main build config, you can find it under ui-build/webpack-for-karma
there are no notable changes outside of breaking that config into a few
files
~ TEST PLAN ~
+-=---------!
- karma/QUnit suite actually runs and passes
Change-Id: Iff474a3d0068441dc8a7c4de605765d936e8ab6d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283377
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Reviewed-by: Sean Scally <sean.scally@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
refs FOO-2697
flag = none
stop relying on @instructure/ui-babel-preset and instead use exactly the
transforms that we still need today from Babel
transformations that appear to be no longer necessary:
- plugin-transform-destructuring
- plugin-proposal-decorators
- plugin-proposal-class-properties
- plugin-proposal-export-default-from
- plugin-proposal-object-rest-spread
- plugin-proposal-optional-chaining
- plugin-syntax-dynamic-import
- plugin-proposal-private-methods
- postcss et al (we only import 3-4 css sources and they all come from
node_modules, we don't use themeable on core)
transformations that i don't think are necessary:
- babel-plugin-transform-undefined-to-void: because if there is code
that is re-assigning `undefined`, the solution would be not to humor
it but to stop using it and perhaps file a lawsuit
babel deps were pinned to avoid semver upgrading, because upgrading
within the 7 line is already breaking us and i'll deal with that
another day
~ TEST PLAN ~
\ ---- ---- /
- you can run webpack locally and see no visual artifacts
Change-Id: I64eb9a7ac94e17f730686f579cf67cd8bd4e12f2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/283142
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Sean Scally <sean.scally@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
flag=none
test-plan:
- crystalball map still generates with istanbul
Change-Id: Ie1be76ba9f1ecbe55af8a3c3a499b6b34f6f5f01
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/282683
Reviewed-by: Manoel Quirino <manoel.quirino@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Brian Watson <bwatson@instructure.com>
Product-Review: Brian Watson <bwatson@instructure.com>
closes MAT-470
flag=new_equation_editor
test plan:
- Navigate to RCE instance
- Open equation editor
- Click a toolbar button
> Verify that the equation is added to the text area
> Verify that the editor preserves the text from
initial and advanced views(use toggle button)
> Verify that modifying text from advanced view
updates the equation preview
test plan:
- Navigate to RCE instance
- Select an already created equation image
> Verify that the modal initializes with the selected
equation
Change-Id: I05255e9cc40441f5a060198a66ac151f63d14fd1
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/278860
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
QA-Review: Weston Dransfield <wdransfield@instructure.com>
Product-Review: David Lyons <lyons@instructure.com>
we likely went over our size allotment due to the introduction
of Thai locale
flag = none
test plan:
• builds pass
Change-Id: I1220298de40753f87db4928d9912858249bc7a71
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/279213
Reviewed-by: Andrea Cirulli <andrea.cirulli@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: August Thornton <august@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
fixes FOO-2493
flag = none
test plan:
• compile assets and ensure Rails and Webpack are ran with
the following ENV variable: RAILS_LOAD_ALL_LOCALES=1
• change your language via profile/course/account to:
• Thai (ไทย)
• verify _most_ strings are being translated properly
• see Thai within our Style Guide for verifications below
• https://instructure.atlassian.net/wiki/spaces/ENG/pages/134802178/ \
Style+Guide+-+Instructure#StyleGuide-Instructure-Thai
• verify the RCE is localized
• verify assignment edit date picker (JQuery) works as expected
• selecting specific days, hours/minutes, and typing
• verify we're formatting the numbers as expected by punching in a
large number into "Points"
• verify the assignment index date picker(React) is localized
• go to calendar and verify the month/day names look appropriate
for the Thai locale
Change-Id: I9de044775b3ee492b8cc96e6d1234d64462c94b6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276201
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Jesse Poulos <jpoulos@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
fixes FOO-2494
flag = none
test plan:
• compile assets and ensure Rails and Webpack are ran with
the following ENV variable: RAILS_LOAD_ALL_LOCALES=1
• change your language via profile/course/account to:
• Español (españa)
• verify _most_ strings are being translated properly
• see Spanish (Spain) in our Style Guide for verifications below
• https://instructure.atlassian.net/wiki/spaces/ENG/pages/134802178/ \
Style+Guide+-+Instructure#StyleGuide-Instructure-Spanish(Spain)
• verify the RCE is localized
• verify assignment edit date picker (JQuery) works as expected
• selecting specific days, hours/minutes, and typing
• verify we're formatting the numbers as expected by punching in a
large number into "Points"
• verify the assignment index date picker(React) is localized
• go to calendar and verify the month/day names look appropriate
for the Español (españa) es-ES locale
• please note that we fall back to es Spanish (Latin America) for
Moment and TinyMCE (canvas-rce)
Change-Id: I441d5c15fcfb55c8695d7b82c643ab74c68318b2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276642
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
This moves us toward resolution of the following warning:
DeprecationWarning: Tapable.plugin is deprecated.
Use new API on `.hooks` instead
Test plan:
- tests pass
Closes FOO-2563
flag=none
Change-Id: I69429eac6e971268b722ed347d7b4a37473cd622
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/278023
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
This moves us toward resolution of the following warning:
DeprecationWarning: Tapable.plugin is deprecated.
Use new API on `.hooks` instead
Pork: prettify ui-build/webpack/index.js
Test plan:
- Tests pass
Closes FOO-2562
flag=none
Change-Id: I342d0679c29721866adf979967434b6946f0ef7e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/277926
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Reviewed-by: Eduardo Escobar <eduardo.escobar@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Syed Hussain <shussain@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
minor QOL mainly for me; put webpack-specific configuration in its own
folder, make it portable, and make room for esbuild
the __webpack_public_path__ initializer no longer sources the value from
the build module, instead it uses a pre-defined global that webpack
injects
~ test plan ~
build is OK
Change-Id: I4ba4a3c0cb9175f96096f2b78022e152c04fc75d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/276183
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
Aaron Ogata