[rkward-devel] i18n in JS - request for comments

[Thomas Friedrichsmeier]

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")

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141101/f50a5584/attachment.sig>