[WG: I18N & L10N] Best way to handle i18n bundles in client side Javascript
Steve Swinsburg
steve.swinsburg at gmail.com
Tue Jul 10 05:37:58 PDT 2012
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>> 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>> 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>> 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>
>>>> 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> 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>
>>> 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> 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>
>> 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.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/i18n/attachments/20120710/56f1c43f/attachment-0001.html
More information about the i18n
mailing list