[WG: I18N & L10N] Best way to handle i18n bundles in client side Javascript
Matthew Jones
matthew at longsight.com
Wed Jul 18 19:46:18 PDT 2012
Agreed, you still need to do a few things do some server side code to
minimally pass the users or sites locale (SAK-10393) as a javascript
variable.
And also note that this method won't work with database loaded properties
(SAK-18678 - which also currently don't work with messages in services) or
centralized properties (SAK-15037). All properties used have to be defined
in the tool as mentioned. So minor limitations (at the moment) perhaps. I
did want to start making more use of SAK-18678.
If you think this method
- Add plugin to unpack in pom
-
Add ./library/js//jquery/i18n-properties/1.0.9/jquery.i18n.properties-min-1.0.9.js
and use that
- Pass in language as variable from server side code
should be best practice I'm happy with it, I'd just like it documented
outside of email and slideshare slides. ;) (I'd also be happy to do this,
just was mostly looking for some reassurance from the i18n experts)
https://confluence.sakaiproject.org/display/I18N
/Best+Practices+for+Internationalized+Tools+in+Sakai#BestPracticesforInternationalizedToolsinSakai-Javascriptbasedtoolsjavascript
And we probably should get that plugin into
On Tue, Jul 10, 2012 at 7:19 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:
> A provider would be fine, but it is probably overkill? Apart from client
> side apps, no other tool is going to need to access the i18n properties of
> another tool, so wouldn't it be easier to add some build time code to
> unpack the bundle into the webapp, rather that add provider support for
> every tool that you need?
>
> cheers,
> S
>
>
>
> On 11/07/2012, at 12:57 AM, Matthew Jones wrote:
>
> Thanks Steve,
>
> I think that Lovemore's or this could work for the short term for me. I
> only have 2 strings so just pushing those in through the velocity template
> could work too.
>
> I think I was more asking would anyone was either for/against (or had
> written) a generic /direct/i18n (if this seems appropriate) that could be
> used to get any tools message bundle json feeds. This would would
> incorporate SAK-18678 (Dynamic localization via database) & SAK-15037
> (Centralized Bundles) (since it would access the ResourceLoader) as well as
> anything else that came up? This seems like it would be easy for 2.10+ and
> a good long term idea if javascript will continue being used in some places
> to enhance the UI.
>
> On Tue, Jul 10, 2012 at 8:37 AM, Steve Swinsburg <
> steve.swinsburg at gmail.com> wrote:
>
>> Heres the example code I was talking about earlier. The bundle module of
>> Profile2 is packaged as a jar and available as a dependency to various
>> parts of the app, then it is explicitly unpacked and made available as a
>> web resource in the webapp. This particular plugin is activated in the
>> 'tool'.
>>
>> One source, multiple locations.
>>
>> cheers,
>> Steve
>>
>> <!-- Unpack resource bundles JAR into webapp/bundle -->
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-dependency-plugin</artifactId>
>> <executions>
>> <execution>
>> <id>unpack</id>
>> <phase>process-resources</phase>
>> <goals>
>> <goal>unpack</goal>
>> </goals>
>> <configuration>
>> <artifactItems>
>> <artifactItem>
>> <groupId>org.sakaiproject.profile2</groupId>
>> <artifactId>profile2-bundle</artifactId>
>> <type>jar</type>
>> <overWrite>false</overWrite>
>> <outputDirectory>${project.build.directory}/${project.build.finalName}/bundle</outputDirectory>
>> <includes>**/*.properties</includes>
>> <excludes />
>> </artifactItem>
>> </artifactItems>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>>
>>
>>
>>
>>
>>
>> On 10/07/2012, at 10:17 PM, Jean-Francois Leveque wrote:
>>
>> I think using the ResourceLoader leads to compatibility with SAK-18678.
>> This is a reason for doing it the way Lovemore has shown us is good
>> unless we have a better way to do the same.
>>
>> SAK-15037 means loading another bundle, which is centralized. We already
>> have examples for this, but not with javascript AFAICT.
>>
>> I'm back and busy today, please ask if you need more information.
>>
>> J-F
>>
>> On 06/07/2012 20:37, Matthew Jones wrote:
>>
>> Right, but for this to work your properties have to both be packaged in
>>
>> the jar (the typical default so resource loader can get to it in shared)
>>
>> and available in the webapp to the tool. AFAIK there isn't any
>>
>> documentation for doing both from one source, either packing the jar
>>
>> then copying the bundle somewhere to the webapp during the build or
>>
>> something else. So this is a slightly annoying step.
>>
>>
>> And there's no /direct interface I've found to get the user's locale, so
>>
>> that would still have to be present in every Javascript that needs to
>>
>> use this, as well as the full path to the web accessible bundles.
>>
>>
>> I'm not saying that this isn't a possible way to do it, but I can't find
>>
>> any decent documentation for achieving this at all., was just hoping
>>
>> there was some already. :/
>>
>>
>> Another thing about just using the jQuery.i18n.properties would mean
>>
>> that using any service that can dynamically update properties
>>
>> (SAK-18678),or any centralized properties (SAK-15037) wouldn't be
>>
>> present in these files either, so there's at least these 2 edge cases
>>
>> which could be avoided with a *general* /direct/i18n or similar interface.
>>
>>
>> On Jul 6, 2012 1:37 PM, "Feliz Gouveia" <fribeiro at ufp.edu.pt
>>
>> <mailto:fribeiro at ufp.edu.pt <fribeiro at ufp.edu.pt>>> wrote:
>>
>>
>> I think we used the jQuery.i18n.properties plugin. Maybe Nuno can
>>
>> confirm that.
>>
>>
>> Feliz
>>
>>
>> http://archive.plugins.jquery.com/project/jquery_i18n_properties
>>
>>
>> On 6 July 2012 17:46, Aaron Zeckoski <azeckoski at unicon.net
>>
>> <mailto:azeckoski at unicon.net <azeckoski at unicon.net>>> wrote:
>>
>> I generally solve this by putting the keys into the page html source
>>
>> or passing the key and text with the relevant request if the first
>>
>> option doesn't work (based on the current user). The problem with
>>
>> trying to pass a massive set of keys is that it is a lot of data and
>>
>> if you aren't careful you can begin to overwhelm the memory available
>>
>> in the browser (especially on a tablet or mobile device) and the page
>>
>> loads (or at least the first JS operation loads) are slowed down
>>
>> waiting for the synchronous request to get the entire set to
>>
>> complete.
>>
>>
>> The shortcut method for passing all the keys and translated values
>>
>> sorta works but it is kind of the lazy way to solve it and has some
>>
>> drawbacks (as mentioned above). I'm not a big fan of passing lots of
>>
>> data you don't need just on the off chance that you might need it but
>>
>> that's just a personal preference.
>>
>>
>> -AZ
>>
>>
>>
>> On Fri, Jul 6, 2012 at 11:41 AM, Matthew Jones
>>
>> <matthew at longsight.com <mailto:matthew at longsight.com<matthew at longsight.com>>>
>> wrote:
>>
>> I was recently working on on feature on Schedule/Calendar which
>>
>> was making
>>
>> some ajax calls all client side, and I wanted to pass some
>>
>> return text back
>>
>> based on a success or failure. Ideally this message would be
>>
>> displayed in
>>
>> the UI and be i18n'd, however when searching through the docs,
>>
>> they were
>>
>> mostly incomplete relating the javascript and there didn't
>>
>> appear to be any
>>
>> great existing way of doing it.
>>
>>
>>
>> https://confluence.sakaiproject.org/display/I18N/Best+Practices+for+Internationalized+Tools+in+Sakai#BestPracticesforInternationalizedToolsinSakai-Javascriptbasedtoolsjavascript
>>
>>
>> What was there was a presentation from Lovemore about how for
>>
>> evaluation,
>>
>> they created a new Provider (the EvalResourcesProvider) which
>>
>> returns json
>>
>> pairs of all messages in evaluation. I was thinking it would be
>>
>> great if
>>
>> rather than having every tool write this, we could have a
>>
>> central provider
>>
>> (maybe in the config project) which could return json for any
>>
>> message bundle
>>
>> and any locale (or the current users preferred locale if not
>>
>> specified).
>>
>> Ideally an external way to:
>>
>>
>> String getString(bundleName,key) {
>>
>>
>> return ResourceBundle.getBundle(bundleName,
>>
>> getUserPreferredLocale()).getString(key);
>>
>>
>> }
>>
>>
>> Or possibly more efficiently, just return the entire bundle in the
>>
>> UsersPreferredLocale as json.
>>
>>
>> ResourceBundle getBundle(bundleName) {
>>
>>
>> return ResourceBundle.getBundle(bundleName,
>>
>> getUserPreferredLocale();
>>
>>
>> }
>>
>>
>>
>> The problem is that otherwise there's no way to know the users
>>
>> preferred
>>
>> locale, and there's no reliable way to get the properties off of
>>
>> a standard
>>
>> http call (like with the jquery-i18n-properties library). The
>>
>> only other way
>>
>> I can think of is to pass the entire bundle (or at least the
>>
>> values I need)
>>
>> as javascript values when creating the template, but this seems
>>
>> easier in
>>
>> the long run.
>>
>>
>> Has anyone thought about this any further and did any work on this?
>>
>>
>> Thanks!
>>
>>
>> _______________________________________________
>>
>> i18n mailing list
>>
>> i18n at collab.sakaiproject.org <mailto:i18n at collab.sakaiproject.org<i18n at collab.sakaiproject.org>
>> >
>>
>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>
>>
>> TO UNSUBSCRIBE: send email to
>>
>> i18n-unsubscribe at collab.sakaiproject.org
>>
>> <mailto:i18n-unsubscribe at collab.sakaiproject.org<i18n-unsubscribe at collab.sakaiproject.org>>
>> with
>>
>> a subject of "unsubscribe"
>>
>>
>>
>>
>> --
>>
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>
>> _______________________________________________
>>
>> i18n mailing list
>>
>> i18n at collab.sakaiproject.org <mailto:i18n at collab.sakaiproject.org<i18n at collab.sakaiproject.org>
>> >
>>
>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>
>>
>> TO UNSUBSCRIBE: send email to
>>
>> i18n-unsubscribe at collab.sakaiproject.org
>>
>> <mailto:i18n-unsubscribe at collab.sakaiproject.org<i18n-unsubscribe at collab.sakaiproject.org>>
>> with a subject of
>>
>> "unsubscribe"
>>
>>
>>
>>
>> --
>>
>> Feliz Ribeiro Gouveia
>>
>>
>> Universidade Fernando Pessoa http://www.ufp.pt
>>
>> Centro de Recursos Multimediaticos Tel 351-22.507.13.06
>>
>> M.I.N.D. Lab Fax 351-22.550.82.69
>>
>> Pr 9 de Abril 349 fribeiro at ufp.edu.pt <mailto:fribeiro at ufp.edu.pt<fribeiro at ufp.edu.pt>
>> >
>>
>> P-4249-004 Porto
>>
>> _______________________________________________
>> i18n mailing list
>> i18n at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>
>> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.orgwith a subject of "unsubscribe"
>>
>>
>>
>> _______________________________________________
>> i18n mailing list
>> i18n at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/i18n
>>
>> TO UNSUBSCRIBE: send email to i18n-unsubscribe at collab.sakaiproject.orgwith a subject of "unsubscribe"
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20120718/74bca131/attachment-0001.html
More information about the i18n
mailing list