search

eligrey / l10n.js

Passive localization JavaScript library
http://purl.eligrey.com/l10n.js
Other
392 stars 68 forks source link

Adding compatibility with Java/C style locales #3

Closed dustyjewett closed 13 years ago

dustyjewett commented 13 years ago

As most programming languages don't follow the ISO standard, adding in this one statement will enable better compatibility.

eligrey commented 13 years ago

Sorry, but I'm pretty sure my l10n.js JSON format is already incompatible with all Java and C l10n libs to begin with. If you're generating l10n.js JSON on a server that's using Java or C style locales, it should be easy to convert them to the appropriate locales. Btw, replace("_","-") only replaces the first _. You want replace(/_/g,"-").

dustyjewett commented 13 years ago

Good call on the replace.. we don't use more than one extended tag in any of our tests.

I'm not worried about generating JSON on the server... I'm worried about 3rd party sites passing in a locale using the pervasive-but-not-standard underscore through urlparams.

Not a big deal, but I can't see how accepting otherwise-validly-generated locales would be anything but a good thing.

On Tue, Mar 22, 2011 at 8:15 PM, eligrey < reply@reply.github.com>wrote:

Sorry, but I'm pretty sure my l10n.js JSON format is already incompatible with all Java and C l10n libs to begin with. If you're generating l10n.js JSON on a server that's using Java or C style locales, it should be easy to convert them to the appropriate locales. Btw, replace("_","-") only replaces the first _. You want replace(/_/g,"-").

Reply to this email directly or view it on GitHub: https://github.com/eligrey/l10n.js/pull/3#issuecomment-906116

eligrey commented 13 years ago

If for some reason a third party absolutely refuses to change their locale code usage to the standard format, then you should handle that on your first party server, replacing the underscores before handling. If you are the third party in this situation, then just replace the dashes with underscores whenever necessary. l10n.js is a client-side framework that shouldn't have to bend over backwards for irrelevant server-side frameworks. If this issue is very important to you, just keep your fork up to date. This won't be hard, as l10n.js is quite simple and it's very unlikely that I will ever need to fix a bug in the near future.