I second Norbert's concerns. I think there's something here, but how all this should work from the standpoint of internationalization isn't fully baked.
--Rich Gillam Lab126 On Jul 2, 2012, at 8:30 PM, Norbert Lindenberg wrote: > The quasi-literal proposal discusses at some length text localization [1]. > After reading the section and then realizing that most of the discussed > functionality is not actually part of the proposal, I'd like to ask that the > discussion of localization in this context be removed. > > 1) The discussion of the msg function is very incomplete with regards to the > current state of the art in internationalized message construction. Modern > message formatting libraries include support for plural and gender handling, > which is not discussed here [2], and offer far more comprehensive number and > date formatting than discussed here. The msg function also doesn't integrate > with the ECMAScript Internationalization API [3]. > > 2) Quasi-literals are based on the assumption that the pattern strings are > normally embedded in the source code. In internationalization, that's called > "hard-coded strings" and generally considered a really bad idea. Normally, > you want to separate localizable text and data from the source code, so that > localization can proceed and languages can be added without changes to the > code. I'm aware that some companies are using a localization process that > involves generating localized source files with embedded strings. This may be > viable for web application where the code is hosted on a server and sent to > the browser for execution each time the application is started. I don't see > how it would work for applications that actually run on the server (e.g., > within Node.js) and where the server has to provide localized responses in > different languages for each request. I don't think it's viable either for > applications that are made available through an application store (e.g., > those bu il > t with PhoneGap or Titanium) and which have to include support for multiple > applications with minimal download size. > > 3) The workaround discussed to support purely dynamic message replacement > (which I'd consider the normal path from an internationalization point of > view) seems to be duplicating much of the work involved in interpreting > quasi-literals, but loses the variable names on the way, and doesn't permit > passing through variables that aren't used in the original quasi-literal. The > latter is necessary, for example, in the context of gender handling: > Sentences may be gender dependent in some localized languages while not in > the source language. > > Regards, > Norbert > > [1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis > [2] https://docs.google.com/present/view?id=ddsrrpj5_68gkkvv6hs > [3] http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
