Bugzilla – Full Text Bug Listing
| Summary: | Localization 404s | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Simon Kaegi <simon_kaegi> |
| Component: | Client | Assignee: | Malgorzata Janczarska <malgorzata.tomczyk> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne, malgorzata.tomczyk, Silenio_Quarti |
| Version: | 0.5 | ||
| Target Milestone: | 0.5 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 375700 | ||
| Bug Blocks: | |||
|
Description
Simon Kaegi
This is really a difficult issue: first the new language pack bundle is supposed to be installed without any modification in existing files (Babel requirement), on the other hand for requireJS we should know what locales are supported before we try to load them. The 404's come from a hack that checks if locale exists, because is return the list of locales to requireJS. >Another problem is that it does not allow us to consume localizations that are not co-located with the server. What does "co-located" mean? That they are deployed on a different server? RequireJS and Dojo 1.7 require the language pack to be in a precise location, relative to master messages file. I never came across a way to define a remote localization bundle. I reopened bug 375700, because there is another reason to change this approach. Gosia, I'm going to take this bug for the first bit before re-assigning back to you. The approach I would like us to take here is a slight variation on what we currently have. At the moment the "root" message provider is doing the majority of the 18n work "synchronously" on the fly in a function. I think the idea of using a function is really powerful and would like to change this slightly to remedy the problems in this bug. I'd like to have the function just return the root translation and then consults a "well-known" location in localstorage to provide a list of additional languages. The idea here is to continue to give the external appearance of just using the vanilla 18n support provided by requirejs but doing some extra work under the covers to handle dynamic addition of new languages. I have some work to do on the requirejs side to pre-define and allow deferred resolution of the associated language message modules (hopefully avoiding the xhr discovery and allowing cross-domain translations). The contents of these non-root message modules will just be regular 18n modules although the contents will come from an appropriate "message localization provider(?)" registered in the service registry. The reality is likely to be a bit messier but I think this approach has a good chance of being workable. If the approach using the deferred resolution of message bundles does not work well we can still go ahead with the metadata localstorage approach to populate the languages in the root message but instead just have the regular requirejs 18n plugin load using xhr. To be honest I'm not sure of the time impact of the ripple on effects of this change (e.g. having to have message plugins instead of just i18n js files) so we might just go for the xhr approach in the interim. I think localization is important for 0.5 and still would like to see if we can do this for m2. I'll try to do my piece tomorrow and update this bug as I know more. I will likely need some help the day after to integrate with a translation to validate. Simon, yesterday we where talking about one change more: current approach is to load the language packs on the server site and we wanted to load them on the client site as a plugin. I like the idea of consulting the "well known" place in local storage, it will solve all the problems described in this bug, but we still have to have an idea how would the local storage be populated. If language packs where plugged in on the client site this would solve the problem: when installing the language pack plugin information would updated in the local storage. It is also quite important that we checked the presence of the translation per message file, because if we add a supported language to the list, but the translation for this messages module does not exist requirejs will not load the page at all. The module may be empty (all strings are then in English), but has to exist. Simon did a lot of changes here to enable loading language packs as plugins (thank you Simon!). I have to change some of the messages files a little bit to meet the Babel requirements and then I will continue working on creating the new language pack format in bug 375700. The work is done |