[development] translation for the installer?
gabor at hojtsy.hu
Fri Jul 14 21:19:26 UTC 2006
On Fri, 14 Jul 2006, Stefan Nagtegaal wrote:
> What I want for a long time is totally remove the generation/parsing of .po
> files from drupal.. It is a heavy process (I've heared that, so don't blaim
> me when I talk rubbish), and IMO a one time setup job you once do, and never
> touches again..
Indeed, it is a heavy process and a complicated one. Lots of PHP code to
parse and generate PO files.
> What I wanted todo is have another file in each module like eg. node.
> $language.translation, blog.$language.translation, etc, etc which does
> something like this:
> $translation = array(
> 'node_menu_item_add_content' => 'add content',
> 'node_menu_local_task_' => 'edit',
> and then we could parse these files with the module which needs it. The
"Then we could parse..." This keyed array you propose would kill t()-s, in
that they would not show what is the text itself. Code would be a lot
harder to undestand, edit and update. It also means a lot different
workflow then the current PO based translation. You might have noticed
that after we introduced PO file support for translation (which has nice
desktop tools to work with), the number of translations skyrocketed. And
they are in a good shape! See: http://drupal.org/translation-status
Of course the fact that we give POT files to translators and get PO files
from them does not mean we need to give the PO files to Drupal. We can
generate whatever we want from those PO files (eg. SQL import scripts to
put into module folders run by the module installer when a module is
There can be some problems with this approach though:
- using PO files allows us to let anyone down the chain modify the
translation easily and reimport (no need to fiddle on the admin
interface which is far from friendly if you need to change multiple
- using PO files allows us to look for prospecting projects like
utilizing the gettext PHP extension, which is expected (although
not proved) to be quicker then hammering the database with t()
requests [note that gettext is a rarely setup extension to PHP,
so it should not be relied upon completely]
> biggest improvement (IMO) will be that homonyms (words with different
> meanings depending on the context/page they are displayed) will be easily
> solved (I think)..
Some people in the Hungarian translation also faced homonym problems, but
I think your solution is not what Drupal needs to possibly solve them.
> programmer, and I am certainly not a drupalguru. I just hope you understand
> the reason behind this, and also do understand why I encourage some system
> like this. So please don't burn me down, but give it some serious thought..
I hope my comments will not be regarded as burning down. The locale system
got quite some thought when we developed it, mostly to be better
human-compatible for translators. It was successful in this way before the
theme system, which goes into the same direction. It is important to keep
the human factor in mind, not just some implementation easyness.
More information about the development