--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/fbc0ffa6-73b8-423c-a900-a04f105ba82b%40googlegroups.com.
Andy Armstrong
edX | UI Architect | an...@edx.org
141 Portland Street, 9th floor
Cambridge, MA 02139
http://www.edx.orgThanks Andy,
Thanks Andy,But I can't see JIRA ticket... Is there any specific permission which I don't have?
--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/23a41b73-bf90-475c-8c5e-d4d7372f6a01%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/b46d701e-1294-4717-8715-319f3380d0f7%40googlegroups.com.
Hi Andy,
> You need to create a free JIRA/Confluence account to access our tickets. See this wiki page for details:
Same problem here. I have a JIRA account and I am logged-in, yet I can't see the bug description due to permission issues.
Greetings,
Juanan
As an XBlock developer, my ideal solution would look like this:
1. Some simple tool can scan my XBlock's code and extract strings for both python and JS and then output per-language files within my XBlock's python module directory, e.g. drag_and_drop_v2/translations/eo/LC_MESSAGES/text.po and text_js.po
2. The XBlock JavaScript Runtime API (which provides e.g. the "runtime.handlerUrl(element, method)" method) should have three new methods: gettext(), ngettext(), and getLocale()
3. The runtime should guarantee that calls to gettext() and ngettext() are synchronous and non-blocking (i.e. that the appropriate strings .js file is optimistically loaded).
4. The runtime should provide a polyfill for the JavaScript Intl API (for Safari and mobile browsers)
Notes:
Re #2: It is important to implement all three methods - gettext is obvious, ngettext is very important, and getLocale() allows authors to use all rich, browser-native i18n formatting tools for dates, numbers, etc. For example, an XBlock in an accounting course can use
function myXBlock(runtime, element, args) { const locale = runtime.getLocale(); // Format a currency amount like "USD $-1,234.56" in a locale-appropriate way, e.g. "-$1,234.56" for en-US or "-1.234,56\xa0$" for de-DE const amount = 1234.56; const usdAmountAsString = amount.toLocaleString(locale, {style: "currency", currency: "USD"}); $(element).template(foo, {amtStr: usdAmountAsString}); }
In terms of LMS implementation, I think that at build time, the LMS static pipeline should scan for all installed XBlocks, and then build compressed .js string files - either:
1. a per-language file that combines the strings of all installed XBlocks (but keeps them separate, grouped by the python package name that contains them), or
2. a separate file per-language and per-XBlock-python-package. This is probably the only way to go for installations with lots of installed XBlocks like edx.org?
IMHO It is important to group the strings by python package and not by, say, block type or XBlock entry point, because some XBlocks consist of multiple related XBlocks within the same python package that will want to share strings.
--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CALc7hq9JeM4dK5hWUXuNDTfumcRtjbCJDoLpqg8MnFgUCRZT6w%40mail.gmail.com.