translation for the installer?
Hi, I looked through the installer code. It obvisouly does not even try to t() strings, since a database is not yet in place. My quite is how to tackle the issue of translating the installer to different languages. - do not care about this, the installer is just a short process, only database setup, and then the profile can easily handle importing the translation and then on use that translation for install wizards - load in the PO import code (locale.inc) and import a PO file for the installer if available into memory. the installer PO file should be small, so this should not be a resource problem. - come up with some custom process of providing translations for the installer, like a simple key->value pair text file. Since PO parsing is already done, translators are already familiar with PO editing and translation, the second option might be doable. We just need a simplified t() implementation for the installer, which works from the associative array loaded in by the PO import code. It would be nice to provide a localized installer from the very start, and with the solutions proposed it would only need another file (installer.po) copied into the profiles folder before running the installer. (This is a development issue, not a translation one, this is why I brought it up here). Gabor
Op 14-jul-2006, om 15:45 heeft Gabor Hojtsy het volgende geschreven:
Hi,
I looked through the installer code. It obvisouly does not even try to t() strings, since a database is not yet in place. My quite is how to tackle the issue of translating the installer to different languages.
- do not care about this, the installer is just a short process, only database setup, and then the profile can easily handle importing the translation and then on use that translation for install wizards
- load in the PO import code (locale.inc) and import a PO file for the installer if available into memory. the installer PO file should be small, so this should not be a resource problem.
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
Since PO parsing is already done, translators are already familiar with PO editing and translation, the second option might be doable. We just need a simplified t() implementation for the installer, which works from the associative array loaded in by the PO import code.
It would be nice to provide a localized installer from the very start, and with the solutions proposed it would only need another file (installer.po) copied into the profiles folder before running the installer.
(This is a development issue, not a translation one, this is why I brought it up here).
Gabor
Well, I do have an opinion about that.. 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.. 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 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).. Goba, Idon''t know if you (dis)like this approach, but I just wanted to inform you about my head spinnings over a couple of years. i'm not a good 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.. Would/Could it be possible? Maybe even as a contrib-module? I think it would certainly speed up things, but I do not have any numbers.. Stefan
Stefan Nagtegaal wrote:
Op 14-jul-2006, om 15:45 heeft Gabor Hojtsy het volgende geschreven:
Hi,
I looked through the installer code. It obvisouly does not even try to t() strings, since a database is not yet in place. My quite is how to tackle the issue of translating the installer to different languages.
- do not care about this, the installer is just a short process, only database setup, and then the profile can easily handle importing the translation and then on use that translation for install wizards
- load in the PO import code (locale.inc) and import a PO file for the installer if available into memory. the installer PO file should be small, so this should not be a resource problem.
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
Since PO parsing is already done, translators are already familiar with PO editing and translation, the second option might be doable. We just need a simplified t() implementation for the installer, which works from the associative array loaded in by the PO import code.
This sounds like a feasible solution.
It would be nice to provide a localized installer from the very start, and with the solutions proposed it would only need another file (installer.po) copied into the profiles folder before running the installer.
(This is a development issue, not a translation one, this is why I brought it up here).
Gabor
Well, I do have an opinion about that..
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..
First of all this is totally unrelated to the topic that Goba posted about, namely translation of the installer's interface. Second, a lot of people - including Goba and myself - worked hard to get the PO stuff into core. Third, the reason for this was that translation through PO files is a well established process in the OS community and thus we have been able to get more translations than before.
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 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)..
The only serious problem with homonyms that I am aware of is that the English abbreviatation for May is equal to the non-abbreviated version. I know this to be a problem for the Spanish translators, I am not sure it exists for other languages or other English terms. I am unfortunately unaware of a non-hackish solution to the May problem, but it certainly does not warrant to complicate the translation process in the way you propose it. Cheers, Gerhard
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
Gabor Hojtsy wrote:
- 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]
I've recently tried this and it wasn't much better than our current way of caching t'ed strings. Cheers, Gerhard
On Fri, 14 Jul 2006 15:45:35 +0200 (CEST) Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Hi,
I looked through the installer code. It obvisouly does not even try to t() strings, since a database is not yet in place. My quite is how to tackle the issue of translating the installer to different languages.
- do not care about this, the installer is just a short process, only database setup, and then the profile can easily handle importing the translation and then on use that translation for install wizards
- load in the PO import code (locale.inc) and import a PO file for the installer if available into memory. the installer PO file should be small, so this should not be a resource problem.
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
When I started the installer patch, my intention for translations was to emulate the t() function (under a different name), loading translations from a text file rather than the database, with a simple key-value pair as you describe. Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t() to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer. Cheers, -Jeremy
Jeremy Andrews wrote:
On Fri, 14 Jul 2006 15:45:35 +0200 (CEST) Gabor Hojtsy <gabor@hojtsy.hu> wrote:
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
When I started the installer patch, my intention for translations was to emulate the t() function (under a different name), loading translations from a text file rather than the database, with a simple key-value pair as you describe.
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t() to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer.
t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site. Cheers, Gerhard
Cheers, -Jeremy
On Fri, 14 Jul 2006 18:10:55 +0200 Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Jeremy Andrews wrote:
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t () to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer.
t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site.
Yes, but my point is that there are instances where the same message will need to displayed by the installer and by Drupal core. All messages displayed by drupal core are wrapped in t(). So either t() needs to support non-database translations, or...? A specific example of where this could happen is in the forthcoming requirements api. Cheers, -Jeremy
Jeremy Andrews wrote:
On Fri, 14 Jul 2006 18:10:55 +0200 Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Jeremy Andrews wrote:
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t () to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer. t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site.
Yes, but my point is that there are instances where the same message will need to displayed by the installer and by Drupal core. All messages displayed by drupal core are wrapped in t(). So either t() needs to support non-database translations, or...?
I don't see why the installer can't use the existing PO parsing functions to parse a PO file and then display the result through another function. Cheers, Gerhard
On Fri, 14 Jul 2006, Jeremy Andrews wrote:
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t () to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer.
t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site.
Yes, but my point is that there are instances where the same message will need to displayed by the installer and by Drupal core. All messages displayed by drupal core are wrapped in t(). So either t() needs to support non-database translations, or...?
A specific example of where this could happen is in the forthcoming requirements api.
I think of the installer as that small piece of code setting up the database. After the database is set up, Drupal is loaded fully (with the database in there, module tables created and possibly a translation imported). So we only need a special case for the "without database" phase of the installer. Since parsing a big complete PO file for a translation is a major pain for every installer HTTP request, the parsed PO file should only contain the strings relevant for the installer (which are irrelevant later anyway). To reliably extract these strings for a translation template file, it is a lot easier to have a differently named function. Although since common.inc is not loaded in install time, t() is not defined, so we could reuse the t() name with a different function definition, and this would not affect t() runtime performance [just in case someone finds a way to reliably extract install time t() calls]. Am I right in thinking that the requirements API based stuff will load after the database is ready, so that a full bootstrap can be made and normal translation support utilized? Gabor
On Fri, 14 Jul 2006 23:35:44 +0200 (CEST) Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Am I right in thinking that the requirements API based stuff will load after the database is ready, so that a full bootstrap can be made and normal translation support utilized?
The way I had conceived things when designing the original patch involved checking all requirements prior to performing an installation. Verify there is a supported database of recent enough version available. Verify that the webserver is of a valid version with required mods. Verify that PHP is new enough with required extensions. Etc. It sounds like it makes sense to instead just do a very bare minimum of requirement checking (ie, valid database type) to get the database configured, bootstrap Drupal, and then perform the rest of the requirement checks using the core requirements api. As the installer is tested by a wider set of users, we may find that the "bare minimum of requirement checking" may need to be more than just checking the database type, but I imagine the list would remain small and could easily be hard coded. Cheers, -Jeremy
t() calls locale(), If the locale module is not loaded by the installer then locale() could be defined as needed.. --mark On 7/14/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Jeremy Andrews wrote:
On Fri, 14 Jul 2006 15:45:35 +0200 (CEST) Gabor Hojtsy <gabor@hojtsy.hu> wrote:
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
When I started the installer patch, my intention for translations was to emulate the t() function (under a different name), loading translations from a text file rather than the database, with a simple key-value pair as you describe.
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t() to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer.
t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site.
Cheers, Gerhard
Cheers, -Jeremy
-- mark burdett mark@goodstorm.com +1 (415) 341-2815 [mobile] +1 (415) 223-0305 [office] http://www.goodstorm.com/ 835 Terry Francois St San Francisco CA 94158-2209
Mark, this seemed to be a good observation first, but then I looked into it. t() is in common.inc. The installer bootstraps into DRUPAL_BOOTSTRAP_CONFIGURATION, which is the first bootstrap phase. common.inc is only loaded in DRUPAL_BOOTSTRAP_FULL which is the last phase, and obviously never reached in install time. This is not a problem actually, as we need another function as I will explain elsewhere in this thread. Gabor On Fri, 14 Jul 2006, mark burdett wrote:
t() calls locale(), If the locale module is not loaded by the installer then locale() could be defined as needed..
--mark
On 7/14/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Jeremy Andrews wrote:
On Fri, 14 Jul 2006 15:45:35 +0200 (CEST) Gabor Hojtsy <gabor@hojtsy.hu> wrote:
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
When I started the installer patch, my intention for translations was to emulate the t() function (under a different name), loading translations from a text file rather than the database, with a simple key-value pair as you describe.
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t() to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer.
t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site.
Cheers, Gerhard
Cheers, -Jeremy
-- mark burdett mark@goodstorm.com +1 (415) 341-2815 [mobile] +1 (415) 223-0305 [office] http://www.goodstorm.com/ 835 Terry Francois St San Francisco CA 94158-2209
you could always be sneaky and get something that at least looks similar using $t = create_function(...).... then you'd have $t($string), and wouldn't have to worry about namespace conflicts. On Fri, 2006-07-14 at 23:25 +0200, Gabor Hojtsy wrote:
Mark, this seemed to be a good observation first, but then I looked into it. t() is in common.inc. The installer bootstraps into DRUPAL_BOOTSTRAP_CONFIGURATION, which is the first bootstrap phase. common.inc is only loaded in DRUPAL_BOOTSTRAP_FULL which is the last phase, and obviously never reached in install time. This is not a problem actually, as we need another function as I will explain elsewhere in this thread.
Gabor
On Fri, 14 Jul 2006, mark burdett wrote:
t() calls locale(), If the locale module is not loaded by the installer then locale() could be defined as needed..
--mark
On 7/14/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Jeremy Andrews wrote:
On Fri, 14 Jul 2006 15:45:35 +0200 (CEST) Gabor Hojtsy <gabor@hojtsy.hu> wrote:
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
When I started the installer patch, my intention for translations was to emulate the t() function (under a different name), loading translations from a text file rather than the database, with a simple key-value pair as you describe.
Where you run into a problem is when there's shared messages, ie as is desired by the requirements api which could also be used by Drupal itself when enabling modules, as well as by the installer during initial setup. Any text displayed by Drupal is already wrapped in t(), so I think the logical thing to do is to expand t() to support both reading mappings from text fiels in addition to from the database. Then t() could be consistently used in all code, including the installer.
t() is called at least several dozen times per page, any complication should be avoided. The installer is a one time thing and should not impact the running of the site.
Cheers, Gerhard
Cheers, -Jeremy
-- mark burdett mark@goodstorm.com +1 (415) 341-2815 [mobile] +1 (415) 223-0305 [office] http://www.goodstorm.com/ 835 Terry Francois St San Francisco CA 94158-2209
On Fri, 2006-07-14 at 15:45 +0200, Gabor Hojtsy wrote:
Hi,
I looked through the installer code. It obvisouly does not even try to t() strings, since a database is not yet in place. My quite is how to tackle the issue of translating the installer to different languages.
- do not care about this, the installer is just a short process, only database setup, and then the profile can easily handle importing the translation and then on use that translation for install wizards
-1, When you install OS X or Linux, or even windows I think... The first question you are usually asked is what language you want to use for the installation and the system. I think some experts probably figured out that it was a good idea.
- load in the PO import code (locale.inc) and import a PO file for the installer if available into memory. the installer PO file should be small, so this should not be a resource problem.
+1, why not use what we already got?
- come up with some custom process of providing translations for the installer, like a simple key->value pair text file.
-1, bah. already got PO's and people know how to edit them.
Since PO parsing is already done, translators are already familiar with PO editing and translation, the second option might be doable. We just need a simplified t() implementation for the installer, which works from the associative array loaded in by the PO import code.
It would be nice to provide a localized installer from the very start, and with the solutions proposed it would only need another file (installer.po) copied into the profiles folder before running the installer.
I think necessary.
(This is a development issue, not a translation one, this is why I brought it up here).
Gabor
participants (7)
-
Darrel O'Pry -
Gabor Hojtsy -
Gerhard Killesreiter -
Jeremy Andrews -
Jeremy Andrews -
mark burdett -
Stefan Nagtegaal