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