hi,
we discussed some plans for i18n in the past, but to my knowledge we didn't
actually implement anything yet.
so yesterday, i spent some time on drafting i18n support for plugins built
using the rkwarddev package. i was going for the simplest approach. allthough
it didn't take too much time, and my proposal is probably far from perfect, i
already have something which seems to be working. please have a look!
the idea is as follows:
- each language gets its own full set of plugin files, named
<plugin name>.<lang>.xml
<plugin name>.<lang>.rkh
<plugin name>.<lang>.js
<plugin name>.<lang>.pluginmap
this ensures the files don't get mixed up and makes it easy for humans to
find the right one, if needed. this way, you can ship as many languages in
one plugin package as you like, or just the one you're interested in
- in the <document> root of each of these files, the language is defined
by the attributes "lang" and "xml:lang" (as suggested by
http://www.w3.org/TR/xml-i18n-bp/#AuthLang ). maybe we can drop one.
if RKWard gained support for those attributes, it should be able to detect
that there's several .pluginmaps with the same id but different languages. it
could then offer a choice for the desired language and ignore all other plugin
maps of the same id, and/or make the language configurable in the respective
plugin dialog. with the automatic detection we have right now, it finds
conflicting plugin maps and gives an error, of course.
so far this doesn't involve rkwarddev. so here's how it can be done in the
current svn version of the package:
1. when writing your plugin code, use the new function i18n() to offer
tranlations for parts which need one, like all labels:
check.aov <- rk.XML.cbox(label=i18n(
en="Return 'aov' object",
de="Gebe 'aov' Object zurück"),
value="true", chk=TRUE)
2. *before* you build the plugin, set a language:
rk.set.language("en", "en_EN")
without a language set, i18n() defaults to the first one given, so that
should probably always be english. the second value of rk.set.language()
is an optional locale setting, currently unused, and we could just drop
it, too...
3. now build the plugin: all files should have ".en." in their names
4. set another language:
rk.set.language("de", "de_DE")
5. build plugin again: there should be additional files with ".de." in their
names
6. load and activate either the .en.pluginmap or .de.pluginmap to get the
plugin in english or german, respectively
i18n() is not limited to character strings, it simply returns any element
which matches the language string. this means it can also be used to translate
whole objects, e.g., lists of dropdown options etc.
the process is still a little tiresome because of the repeated builds. if we
go for something like this, i can try to automate it. its more like a proof of
concept.
at least, with this method it just takes a few minutes to fully translate a
set of plugins, without the need for any additional tools, new files or a
total revision of the current XML scheme. since translations are put directly
into the plugin script, the resulting code will always remain equivalent,
indepentenly of the language. untranslated parts will remain as they are. i
admit scripts might get crowded with more supported languages, but that's a
nice problem to have...
here's a more elaborate example, i've translated the main ANOVA plugin:
https://svn.code.sf.net/p/rkward/code/branches/external_plugins/rk.ANOVA/inst/rkward/rkwarddev_ANOVA_plugin_script.R
just let it run in RKWard, it should put the generated files in the current R
temp directory.
what do you think? worth a try?
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20140902/a193605a/attachment.sig>