Comments on: l10n.js: JS localization library

By: Jordan1

Jordan1 — Fri, 14 May 2010 00:07:24 +0000

If you want to use native methods, how about going with localized DTDs? That’s how Firefox implements it.

By: rasmusfl0e

rasmusfl0e — Thu, 13 May 2010 19:51:43 +0000

@eligrey: Good :)
.
You use a “%foo.bar”-pattern – does it mean anything? It looks like it should, but as far as I can tell it’s used directly as a key (the pattern has no real function). I could just go with “fooBar”?
.
String.prototype.toLocaleString doesn’t really make any sense; it’s essentially a lookup in an object with a key – and being so doesn’t make sense for any arbitrary string. It shouldn’t be a String method – just a function that wraps a lookup and takes a string as its argument like the “l” function you propose.

By: EliGrey

EliGrey — Thu, 13 May 2010 19:33:07 +0000

@dbjdbj: I updated the demo to use variable string replacement so the keys are less unsightly, though it never really mattered with gzip compression.

By: dbjdbj

dbjdbj — Thu, 13 May 2010 17:30:59 +0000

There is a lot of data redundancy in that JSON.
Surely “fixable” …

By: leomdg

leomdg — Thu, 13 May 2010 16:11:13 +0000

Wow, every aspect of robust applications are getting attacked by different libraries.. What’s left? What’s to come?

Only JavaScript will flow through the pipes soon…

By: EliGrey

EliGrey — Thu, 13 May 2010 16:04:13 +0000

@both of you: it works with variables too. Nobody is requiring you to use sentences.

By: Baryn

Baryn — Thu, 13 May 2010 15:33:03 +0000

@rasmus

I thought that was a bit weird myself.

It’s nice to have JS localization outside of webOS though! I just finished a project this would have been useful for >_<

By: frickenate

frickenate — Thu, 13 May 2010 14:50:59 +0000

@rasmusfl0e: Thank you for reading my mind and getting to the point. That format is just ridiculous.

By: DhtmlGuy

DhtmlGuy — Thu, 13 May 2010 13:02:31 +0000

@rasmusfl0e: In the article, the author actually uses abstract keys like %title.search. This would be the recommended best practice.

Ideally, if the application is server-based, you would generate the json from the server-side resource files (e.g., java properties), so you’d share keys. (This is what we do in the applications I work on, though, we use our own proprietary i18n framework). This means you can hire a localization translation service and they can just make the locale-specific properties files and not have to touch JScript.

By: rasmusfl0e

rasmusfl0e — Thu, 13 May 2010 12:43:26 +0000

Using full sentences as keys? Nevermind redundancy, ineffecient compression and the search and replace needed to correct spelling/wording mistakes. How about a proper level of abstraction?
.
This is just insane. :(

By: DhtmlGuy

DhtmlGuy — Thu, 13 May 2010 12:32:32 +0000

I also noticed that the i10n.js library actually adds toLocaleString to the String.prototype. The article refers to the method as “the native JavaScript method intended for it”; this confused me for awhile as I was unaware of any ECMA spec version that defined this method on String. You may want to clarify this in the article.

By: DhtmlGuy

DhtmlGuy — Thu, 13 May 2010 12:22:12 +0000

I also have to handle date and numeric formatting differences between locales. I have not seen any built-in support in JScript for the latter yet.
Am I missing something?