There are many
I18N and
L10N TWiki subprojects, mostly linked from
InternationalisationEnhancements, but none of them seem to have a solution to translate the TWiki interface (i.e. skins). This page will hopefully summarize the requirements for that work, and link to the appropriate TWiki pages.
My initial proposal is this:
- Making a simple translation plugin, to be integrated in the TWiki core (I hope)
- Use gettext or something similar to store translations, if at all possible (more tools for translators, clearer separation of program and translations).
- Probably use
Locale::Maketext::Gettext to avoid some common problems with vanilla gettext (see http://www.samag.com/documents/s=1290/sam04010013/
)
As I have very little experience with translations, any help or comments are appreciated.
--
EstebanManchado - 12 Aug 2003
I think it can be done with the current TWiki templating mecanism:
- make skins include a "language" template, e.g
template/language.tmpl
- have skin templates not use anymore english names but
%TMPL:P references, e.g. for the "Edit" link, use %TMPL:P{"LANG_editlink"}%
- in the
template/language.tmpl, have all the LANG_ defined, like:
- US language template file:
- %TMPL:DEF{"LANG_editlink"}%Edit%TMPL:END%
- French language template file:
- %TMPL:DEF{"LANG_editlink"}%Modifier%TMPL:END%
Choosing the language can be done currently by copying / symlinking the
relevant
template/language_fr.tmpl or
template/language_us.tmpl to
template/language.tmpl
or, by using the Theming of templates defined in the
KoalaSkin, that I am to retro-port to the
core, see:
ModularTemplates, you will have the language definitions distributed
as
template/language-fr.tmpl or
template/language.tmpl (default) and use
THEME=xxx,yyy,...,fr
--
ColasNahaboo - 12 Aug 2003
Hi Colas,
The fact that can be done with the current templating system doesn't mean it's the best way to do it
;-) The reasons I don't like using the current templating system for translations are:
- It's ugly for the skin designers. I mean, nobody will understand a template full of
%TMPL:P{"LANG_editlink"} and such. What I propose it something like _(Edit) or perhaps %_("Edit")%, much more manageable.
- Forces skin developers to add and update messages in a different file (making up message ids on the fly, BTW, which distracts oneself from the task at hand), and have quite a bit of discipline to make their skin localized. I don't think many of them would do it, as the maintenance would be very hard. I'm not guessing here: the PHP-Nuke translation system works this way, and I've used it.
- Makes it impossible (by implementation) to have, say, a language by user (that is, more than one language per installation). Although I know you can install variations of the skin, it's kludgy and puts the burden in the system administrator.
- Reinvents (badly) the translation systems wheel, forcing translators to learn yet-another-translation-system. Moreover, no special tools can be used.
- And perhaps the most important one: when the skin changes (adds messages, for example), the skin will give an error or something like that (perhaps the message will be empty). This is awful. With a gettext-like system, the new message, if not translated, would appear in English. Suboptimal, yes, but far better. And anyway you can't make up translations for untranslated messages.
Overall, it reminds me of the PHP-Nuke translation system, which has given me
lots of headaches.
--
EstebanManchado - 13 Aug 2003