| ... | ... | @@ -339,4 +339,22 @@ A third party could provide a translation for a language not covered by the Math |
|
|
|
and providing a `kr.js` file in their `MathJax/localization/kr` directory that defines the details of their translation. If the Korean (kr) locale is selected, MathJax will load `http://mycompany.com/MathJax/localization/kr/kr.js` and any other domain files when they are needed.
|
|
|
|
|
|
|
|
|
|
|
|
## The Translation Files ## |
|
|
\ No newline at end of file |
|
|
|
## The Translation Files ##
|
|
|
|
|
|
|
|
In order to make working MathJax data convenient for translators, we will need to provide the translation strings in one of the standard formats, like `.po` for example. The usual approach is to have a program that scans the code for the `_()` calls and builds the data file from that, and that should work with MathJax as well. The `.po` format supports the domain approach, as well as plural forms, and the idea of multiple forms (e.g., verb versus noun). HTML snippets should be translated into HTML strings, so that
|
|
|
|
|
|
|
|
["Do it ",["b",null,["now!"]]]
|
|
|
|
|
|
|
|
would become
|
|
|
|
|
|
|
|
"Do it <b>now!</b>"
|
|
|
|
|
|
|
|
for translation. The translator would produce an HTML version of the phrase with tags in the proper place (which will be translated back into an HTML snippet for use in MathJax at a later point).
|
|
|
|
|
|
|
|
There are two complications to automating the collection of the strings needing translation. The first is that the use of local definitions for `_()` hide the use of the domain, so there will need to be special processing to obtain the domains. It may be possible to recognize the local definition (if we use a common syntax for that) so that the domain can be handled automatically. Alternatively, one could use special comments to mark the domain regions so that the collection program will be able to handle the domains properly. The latter is probably more reliable, but takes extra steps to be sure to include the comments.
|
|
|
|
|
|
|
|
The second issue is if `_()` is called from within a routine that has the message strings passed to it (so that the message passed to `_()` is not a string literal). This would be the case, for example, if `TEX.Error()` was made to call `_()` for you. Such shorthands are very convenient (and reduce the code size), so it would be good to be able to accommodate this case as well. One approach would be to use comments again to tell the collector program what other functions to treat like `_()`.
|
|
|
|
|
|
|
|
The collector will be run over the various MathJax components that have message strings, and produce individual `.po` for each component. These can be combined to make one large `.po` for translators, or translators could handle them individually. Certainly in the case of third-party extensions, their files will be translated separately.
|
|
|
|
|
|
|
|
Once the translations are obtained (as new `.po` files), we need a second program to turn these into the `.js` files that MathJax needs, in the formats described above. We may want to have control files that tell which domains to combine in the main language file, and which to make as individual domain files. |
|
|
\ No newline at end of file |
