[development] translation for the installer?

[Gabor Hojtsy]

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:
> <?php
>
> $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 
enabled).

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

  - 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.

Goba