Hi all! Ok, so we're getting closer still to fully translatable plugins. One remaining obstacle at this point is dealing with i18n in JS files. I'd like to hear your ideas on some issues with that.
As you may be aware, we use JS scripting in two places: generating the R code,
and scripting UI logic.
Let's consider some issues of each in turn:
1. i18n while generating R code
a) When generating R code from UI settings, at some points we're using
constructs that make translations rather hard: E.g. (taken from t_test.js):
echo ('parameters=list ("Comparing"=paste (names[1], "against", names[2]),
\n');
Now we're having two issues, here: One is the fragmentation of strings. Right
now, I can see no good solution except marking up "Comparing" and "against"
for translation, separately. I.e.:
echo ('parameters=list (' + quote (i18n ("Comparing")) + '=paste (names[1],
' + quote (i18n ("against")) + ', names[2]),\n');
Besides the ugliness, that makes it harder for translators to give a good
translation. Some of that can be overcome by adding translation context, of
course. What I was racking my brain about was whether this could somehow be
made to fit into the proven paradigm of writing
i18n ("Comparing %1 against %2", names[1], names[2])
. But the added difficulty in our case is that some portions of the expression
are string literals, while the others are statements to evaluate in R, _and_
the resulting translated expression must be valid in R (even if some languages
would prefer a different word oder à la "Comparing %1 %2 against"). Ok, again,
I have no solution for this, and I tend to believe there is none. But let me
hear your ideas.
(Actually, one idea is that paste()-constructs like the above should be
avoided as much as possible. But the point is dealing with cases where they
are not easily avoidable.)
b) Another problem seems rather solvable: It looks like for the most part, any
translated strings will also be quoted - because they are "printed" as string
literals for parsing by R. Instead of having to write
echo ('rk.print (' + quote (i18n ("Here's your result")) + ')\n');
we could make it so translated strings are already quoted:
echo ('rk.print (' + i18n ("Here's your result") + ')\n');
This would have some advantages:
- Easier to write and read.
- No danger of breaking a plugin by inserting quote characters in a
translated string (*).
- Would help enforcing a consistent i18n-policy along the lines of:
Translate string literals, do not translate function and variable names in
generated code. (I believe such a policy would make a lot of sense, but feel
free to discuss.)
For exception cases, where quoting is not desirable, we could add
i18n_noquote("message") or (somewhat trickier during string extraction, but
doable) i18n (noquote ("message")). For code-comments I'd consider a dedicated
comment()-function, which would be essentially a shorthand for writing
printIndented ("\t#", "This is a comment")
Now the question is, how to do this best:
- i18n() quotes by default, i18n_noquote() for exceptions
- i18n() quotes by default, i18n (noquote()) for exceptions
- I believe that's my favorite, but see below for my doubts
- i18n() does not quote, qi18n () for quoted translations
And this is where we come to point 2:
2. Scripting UI logic
This is used rather rarely, in comparison, and many plugins that use it do not
need it for any translatable strings. However, those that do would typically
need translated strings unquoted. So would we
- use a different behavior, there (but ideally, I'd like to reduce, not
further the differences between the two types of JS scripting)
- live with having to write i18n(noquote()) or i18n_noquote() in the UI logic
scripts
- live with having to write qi18n() in the R-code generating scripts?
3. i18n vs. automated tests
I think I could sleep better, if we could cover some basics of the
translations in automated testing. Importantly, checking that the translated
plugin remains "equivalent", i.e. no breakage due to quoting issues, or
comparing translated strings against fixed values. Here, I'm thinking our best
bet will be to compare the generated R code for translated and untranslated
plugins, ignoring differences inside quoted strings, and comment regions.
Your thoughts?
Regards
Thomas
(*) Consider this example, where translations are not quoted, automatically:
echo ('rk.print ("' + i18n ("Result of 'cool' test") + ")\n');
Now suppose an unsuspecting translator translates
Result of 'cool' test
as
Ergebnis des "coolen" Tests
using a different quoting char. Then this would yield the following - illegal
- R code in the translated plugin:
rk.print ("Ergebnis des "coolen" Tests")
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
