[WG: I18N & L10N] Best way to handle i18n bundles in client side Javascript

Matthew Jones matthew at longsight.com
Tue Jul 10 07:57:06 PDT 2012


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/20120710/b9914425/attachment-0001.html 


More information about the i18n mailing list