[WG: I18N & L10N] Best way to handle i18n bundles in client side Javascript
Steve Swinsburg
steve.swinsburg at gmail.com
Tue Jul 10 16:19:08 PDT 2012
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>> 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"
>
>
> _______________________________________________
> 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/20120711/8781e768/attachment-0001.html
More information about the i18n
mailing list