https://bugzilla.wikimedia.org/show_bug.cgi?id=35038
--- Comment #25 from Frédéric Wang <fred.w...@free.fr> 2012-11-14 13:19:41 UTC
---
First I'd like to thank you again for providing another solution to
localization in MathJax. I just read the code of jquery.i18n and speaking for
myself I don't think it is really worth trying to integrate it to MathJax. The
source code is small and there are many things that I think could be simplified
if we implement something similar in MathJax. For example, I'm not sure whether
redefining the split function is essential? Or whether you really need jquery
to implement such a library? It seems that you only use it to load the file
asynchronously but MathJax already has an API to do that and for this and the
callback function in i18n.properties, we would rather use our own API to
synchronize with MathJax's code, put feedback to our UI and author's listeners
etc. Also, I think only the "map" mode is really important? We want to allow
users to easily share the translation files and so the possibility to add
Javascript code in the translation files with the "vars" mode does not sound
robust nor secure. There are other weird things like why using
parameters[i].split('='), keeping the first part and putting back the other
parts together, instead of just parameters[i].split('=', 1)? And for multi-line
values, why are these parts from the first line are only put back *after* the
subsequent lines? Similarly in i18n.prop, it seems you are really giving you a
lot of pain to implement a parser from the value to an array... just to finish
with a typo "value.lengh == 1" that fortunately is without consequences.
Mozilla uses a different format for *.properties files [1] where the parameters
are just given by %1$S, %2$S etc and the percent can be represented by %S%%.
That really just seems enough to me as the important point is to be able to
pass the arguments and handle different orders in different languages, as you
mentioned in comment 22. Replacing these placeholders will simply be a matter
of calling the string's "replace" method with the right regexp expression and
substitution function. I guess the Javascript's native regexp system will be
more reliable and efficient (perhaps even more than just constructing the
return value from the computed array).
I suspect we will just use JSON files to do the mapping from a key to a value
and so parseData could just be replaced by our asynchronous file loading API
while i18n.prop could just be replaced by a call to the standard "replace"
method with appropriate parameters as I indicate above. I was not able to find
the MathJax extension/changeset to use the jquery.i18n library. Is it public,
still work in progress? I can't see the automatic digit localization in
jquery.i18n, so perhaps it is implemented somewhere else? Is there anything
important point to consider you'd like to mention besides what you indicate in
comment 22?
Of course, we'd definitely want your translation files and I agree with comment
17 that it is important to have a format supported by Wikimedia and that
follows i18n good practices. It seems that you have a JsonFFS script which
"implements a message format where messages are encoded as key-value pairs in
JSON objects". Would that make sense to you if we use this format? Or do you
prefer to provide *.properties files and let us do the conversion?
Thanks.
[1] https://developer.mozilla.org/en-US/docs/XUL_Tutorial/Property_Files
[2]
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Translate.git;a=tree;f=ffs;hb=HEAD
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
