HI, I want to stress that I am not a programmer but I happened to had participated in a couple of translation projects all of which originating from the linux world. None of them would rely on files tossed around the project but rather they would have separate files, sigled out and being specifically of the type of "language" files. Take for example the "LearningAccess" clone of Koha (I did not participate in that projects). They deviced a mechanism in PHP that allowed the translators just to translate the "language" files into their own languages. To me, a no programmer, it seems a disastrous move, to start an international effort to translate Koha in the way we do it today. Thank God "acli" modified my polish files for the changes he thought relevant. But Paul, who contributed a fantastic solution of text only include files did it only for the French version. Now, I don't complain he was egoistic. He had no choice, rather, because there was only a minor change he proposed. In my opinion, however, Paul's change was crucial for the future of Koha. He showed that the interface may be simple and very functional.... . After what I said, a no programmer at all, please flame me or guide me... . My suggestion is to implement a gettext-like solution where there's a set of files of interest to translators and these and only these files (or images) are to be modified for the i18n to take effect. Imagine a template file changes in the ./default/en/ directory and the author ignores informing about it the rest of the community. Now, everybody (of the international community) is to figure out what changes took place and when they took place, and he is to manually find the lines to be translated and modified. It seems insane to me. Benedict, (only here I repeat: I am a no programer and I may be missing an important point here)
On Wed, Jan 29, 2003 at 03:01:36AM +0100, Benedict said:
HI, I want to stress that I am not a programmer but I happened to had participated in a couple of translation projects all of which originating from the linux world. None of them would rely on files tossed around the project but rather they would have separate files, sigled out and being specifically of the type of "language" files. Take for example the "LearningAccess" clone of Koha (I did not participate in that projects). They deviced a mechanism in PHP that allowed the translators just to translate the "language" files into their own languages.
Hi Benedict You make some valid points, there have been some breakdowns in the way the templates have been translated. I think that the main difference here is though, the templates are not only for language translation. But also for themes. Which complicates things. The other thing with using templates, over the use of say gettext is that it doesnt introduce an OS bias. which may or may not be a good thing :) Just some thoughts. My main impression is though, that it is the process that is wrong, not the method. IE the way templates are being maintained is bad, not the idea of using templates. Im sure all the other developers have comments. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Hi
Just some thoughts. My main impression is though, that it is the process that is wrong, not the method. IE the way templates are being maintained is bad, not the idea of using templates.
Just to add to this. The assumptions that we made at the begining of Koha probably really reflect our bias at Katipo (as both a graphic design and programming house), and I think that experience over the last couple of years has proved some of those assumptions to be wrong. First Assumption: The way that we set up Koha for HLT would not suit anyone else. So not only would you not want to use the same language, but that you wouldn't like the same colours, where things were on the page, even what showed up on the page. THUS we made no effort to extract the language from the HTML (And barely from the perl, although others have worked on that) because we assumed you would want to change *everything*. We continue to assume that people *should* be able to change all those things if they want to, hence the move to HTML template. Second Assumption: There is nothing wrong with that :-) First Surprise: People change very little. Our bread and butter work at Katipo is providing people with user interfaces which tailor a programme/website or whatever to their particular "style". I have just now actaully redone the basic templates for the OPAC into something more "generic" because I've realised otherwise you have a bunch of HLT clones, and that my naff code is causing you all so much heartache. See opac-templates.koha.org for the new look. I have *almost* all the images out of it other than the format ones, and I think all text is now really text. To change the look/text of your site now you'd need to change about 10 template files, some includes for the navigation, and the stylesheet. Cheers Rachel _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
Hi, In article <3E37FE85.9105.122FA51@localhost>, Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
First Assumption: The way that we set up Koha for HLT would not suit anyone else. So not only would you not want to use the same language, but that you wouldn't like the same colours, where things were on the page, even what showed up on the page. THUS we made no effort to extract the language from the HTML (And barely from the perl, although others have worked on that) because we assumed you would want to change *everything*.
I actually find the "no effort to extract the language from the HTML" a bit surprising, because it is stated that a Maori interface was intended (right from the start?). So, sooner or later, HLT would face the same problems as the other "international" translators. But this is also not surprising, since I do it the same way; I don't separate the language from the HTML when I do bilingual pages. So, I guess it is different when things are more-or-less centralized (i.e., you know where to look for changes and what they approximately are) and when things are more decentralized (e.g., "international" translators won't automatically know what to change). I can't really criticize someone when I do things in exactly the same way. -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org>
On Wed, Jan 29, 2003 at 03:35:22PM +1300, Chris Cormack wrote:
My main impression is though, that it is the process that is wrong, not the method. IE the way templates are being maintained is bad, not the idea of using templates.
Templates are good. They just don't go far enough, is all. Templates separate presentation from implementation: the Perl coder can just make sure the code generates correct results, without worrying whether it'll look like; and the web designer can concentrate on the look of the site without having to look at Perl code. But i18n should take this one step further, and separate the language from the presentation, as much as possible. I suspect that in practice, people who design their own templates are going to use the default ones as a model: they'll rearrange the existing elements, rather than inventing whole new applications from scratch. Consequently, a lot of strings will stay the same from one theme to the next. It would be nice to be able to take the default "look", change the colors and logos, and magically have it work in all supported language, even as Koha itself evolves. -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com Null modems were created when God got no handshake.
On Wed, Jan 29, 2003 at 03:01:36AM +0100, Benedict wrote:
Imagine a template file changes in the ./default/en/ directory and the author ignores informing about it the rest of the community. Now, everybody (of the international community) is to figure out what changes took place and when they took place, and he is to manually find the lines to be translated and modified.
In another project of mine, the more common problem was that someone would add an English string, but it would take a long time for it to be translated, especially into some of the less "popular" languages, like Portuguese. One of the advantages of gettext() is that if this happens, the new string will appear in English in all versions, until someone gets around to translating it. In addition, separating all content from translatable strings follows the DRY (Don't Repeat Yourself) principle advocated by "The Pragmatic Programmer." -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com Random answers are my specialty!
Andrew Arensburger wrote:
On Wed, Jan 29, 2003 at 03:01:36AM +0100, Benedict wrote:
Imagine a template file changes in the ./default/en/ directory and the author ignores informing about it the rest of the community. Now, everybody (of the international community) is to figure out what changes took place and when they took place, and he is to manually find the lines to be translated and modified.
In another project of mine, the more common problem was that someone would add an English string, but it would take a long time for it to be translated, especially into some of the less "popular" languages, like Portuguese. One of the advantages of gettext() is that if this happens, the new string will appear in English in all versions, until someone gets around to translating it. In addition, separating all content from translatable strings follows the DRY (Don't Repeat Yourself) principle advocated by "The Pragmatic Programmer."
It's fair to say that I got pretty bored of translating "Logged in as" over and over again. And then I should add that it's all getting very complicated when you don't have just one but 3 or 4 translators : for the french translation we each took a few directories, but didn't have any garantee to end up with a coherent translation. And after a few days, we realized we had used 3 different translations for the quite straightforward "e-mail"... Nicolas
I have no idea how to code but after reading the Maketext documentation this is probably the line we should include wherever an english string should be represented by another language. (it's a great simplification) print $lh->maketext("You won!"), "\n"; In french it should print "Tu as gagne". I am just wondering where these strings would have to live...in template files or in the perl scripts. If template files are to remain clean of any code than this would not be a good idea, would it? Benedict
Here's my proposal: Existing english language template example: --- <TMPL_IF NAME="loggedinuser"> <p align=left>Logged in as: <TMPL_VAR NAME="loggedinuser"> [<a href=/cgi-bin/koha/opac-user.pl>Members Home</a>] [<a href=/cgi-bin/koha/opac-logout.pl>Log Out</a>]</p> <TMPL_ELSE> <p align=left><a href=/cgi-bin/koha/opac-user.pl>Log In</a> to Koha</p> </TMPL_IF> --- would be rewritten as: <TMPL_IF NAME="loggedinuser"> <p align=left> <TMPL_VAR NAME="STRING_LoggedInAs"> <TMPL_VAR NAME="loggedinuser"> [<a href=/cgi-bin/koha/opac-user.pl> <TMPL_VAR NAME="STRING_MembersHome"> </a>] [<a href=/cgi-bin/koha/opac-logout.pl> <TMPL_VAR NAME="STRING_Logout"> </a>]</p> <TMPL_ELSE> <p align=left><a href=/cgi-bin/koha/opac-user.pl> <TMPL_VAR NAME="STRING_LoginToKoha"> </a> </p> </TMPL_IF> --- Then we'd need perl code (most likely in the get_template_and_user subroutine) that would do the following: foreach my $variable ($template->param) { if (/^STRING_(.*)/) { my $string_identifier=$1; $template->param($variable => gettext($string_identifier); } } The gettext() routine could be an internal function, or we could use some other implementation. One problem I've noticed with this is it doesn't allow us to have strings with printf variables in them like: Hello %s, welcome to Koha! Where this would be printed as: printf "Hello %s, welcome to Koha!", $fullname; That means you end up translating the string "Hello" and the string ", welcome to Koha!" separately, and completely out of context. It might be possible to gettext the "Hello %s, welcome to Koha!" string on the perl side, use printf to add the variable substitution and then pass the whole thing into HTML::Template as a single variable, but that defeats a lot of the gains that templating gives us. As an example from above, the "Logged in as..." string might be handled as: my $string=gettext("LoggedInAs"); which would return, in English, "Logged in as %s."; $template->param("STRING_LoggedInAs", sprintf $string, $userid); We would also lose the automatic processing that the get_template_and_auth method gave us (wherein that routine just parsed through all the "STRING_*" variables in the template and translates them from gettext files). It's starting to look to me like it's going to be difficult no matter what route we take. The easiest solution for all is probably the get_template_and_auth method, but we end up translating partial sentences. If there was some way to pass a context, as in: Translate "Hello" as part of the phrase "Hello Steve, Welcome to Koha!". and Translate ", Welcome to Koha" as part of the phrase "Hello Steve, Welcome to Koha!". Off the top of my head, I would envision context phrases being stored elsewhere with a numeric index, and the STRING_phrase variables being extended to allow a context number like STRING_phrase_154 where the 154 would point to a context string. Steve. On 30 Jan 2003, Benedict wrote:
I have no idea how to code but after reading the Maketext documentation this is probably the line we should include wherever an english string should be represented by another language. (it's a great simplification) print $lh->maketext("You won!"), "\n";
In french it should print "Tu as gagne".
I am just wondering where these strings would have to live...in template files or in the perl scripts. If template files are to remain clean of any code than this would not be a good idea, would it?
Benedict
------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
Tonnesen Steve wrote:
It's starting to look to me like it's going to be difficult no matter what route we take. The easiest solution for all is probably the get_template_and_auth method, but we end up translating partial sentences.
Beware the changes in the position of the words in the translation : translating in some languages "Hello Steve, Welcome to Koha" you might end up with Steve before "Hello", or after "Koha"... So I think it's important we don't cut the sentences in too small pieces. Which would also make things much more difficult for the translators if they don't have a clue about the context of the phrase to be translated. Nicolas
In article <1043885808.1540.19.camel@localhost.localdomain>, Benedict <kb2qzv@poczta.wp.pl> wrote:
print $lh->maketext("You won!"), "\n";
In french it should print "Tu as gagne".
I am just wondering where these strings would have to live...in template files or in the perl scripts.
Based on the example, the original English strings will need to live in the perl scripts. After reading the man page in CPAN, I think the translated strings will also need to live in a perl module.
If template files are to remain clean of any code than this would not be a good idea, would it?
I don't think the templates is even allowed to contain code. (See Q.9 in the HTML::Template FAQ in the man page.) The module can still be used, if we create a function to scan the HTML. (This will need to be done some time anyway, if we want to convert to/from UTF-8 on the fly.) However, from a cursory read of the maketext man page, using maketext seems to be fairly involved; because of the feature freeze, I suppose doing such a thing would be considered an experimental new feature and thus should not be done for 1.9/2.0? Any comments, Paul? -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org>
On Thu, Jan 30, 2003 at 01:44:07AM +0000, Ambrose Li <acli@ada.dhs.org> via forwarder wrote:
In article <1043885808.1540.19.camel@localhost.localdomain>, Benedict <kb2qzv@poczta.wp.pl> wrote:
print $lh->maketext("You won!"), "\n";
In french it should print "Tu as gagne".
I am just wondering where these strings would have to live...in template files or in the perl scripts.
Based on the example, the original English strings will need to live in the perl scripts.
After reading the man page in CPAN, I think the translated strings will also need to live in a perl module.
If template files are to remain clean of any code than this would not be a good idea, would it?
I don't think the templates is even allowed to contain code. (See Q.9 in the HTML::Template FAQ in the man page.)
Another option might be to translate the templates at install-time, rather than at run-time. That is, the distribution only contains the English version of "searchresults.tmpl", plus French, Polish, etc. translation files. The installation process then generates the French and Polish templates from these. It pleases me to believe that there might be a slight performance gain from this as well. -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com Objectivity is in the eye of the beholder.
On Wed, 2003-01-29 at 19:36, Andrew Arensburger wrote:
On Thu, Jan 30, 2003 at 01:44:07AM +0000, Ambrose Li <acli@ada.dhs.org> via forwarder wrote:
In article <1043885808.1540.19.camel@localhost.localdomain>, Benedict <kb2qzv@poczta.wp.pl> wrote:
print $lh->maketext("You won!"), "\n";
In french it should print "Tu as gagne".
I am just wondering where these strings would have to live...in template files or in the perl scripts.
Based on the example, the original English strings will need to live in the perl scripts.
After reading the man page in CPAN, I think the translated strings will also need to live in a perl module.
If template files are to remain clean of any code than this would not be a good idea, would it?
I don't think the templates is even allowed to contain code. (See Q.9 in the HTML::Template FAQ in the man page.)
Another option might be to translate the templates at install-time, rather than at run-time. That is, the distribution only contains the English version of "searchresults.tmpl", plus French, Polish, etc. translation files. The installation process then generates the French and Polish templates from these. It pleases me to believe that there might be a slight performance gain from this as well.
Unless I'm not understanding something, this would mean that a single koha installation could not be multilingual. This seems like the wrong direction IMO. Micheas -- Micheas Herman <micheas@micheas.dyns.net>
Hi
Another option might be to translate the templates at install-time, rather than at run-time. That is, the distribution only contains the English version of "searchresults.tmpl", plus French, Polish, etc. translation files. The installation process then generates the French and Polish templates from these. It pleases me to believe that there might be a slight performance gain from this as well.
Unless I'm not understanding something, this would mean that a single koha installation could not be multilingual. This seems like the wrong direction IMO.
If that is the case it seems like a bad idea :-( Cheers R _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
In article <1043899829.32549.20.camel@tux>, Micheas Herman <micheas@micheas.dyns.net> wrote:
On Wed, 2003-01-29 at 19:36, Andrew Arensburger wrote:
[stuff deleted]
Unless I'm not understanding something, this would mean that a single koha installation could not be multilingual. This seems like the wrong direction IMO.
No, what Andrew proposed is that we keep one set of master templates (the English ones), and a set of translation files. At buildrelease time (or install time), translated templates are generated by applying the translations to the master templates. The advantage of this is that we separate theme from language, and make the list of strings to translate explicit. On the other hand, changes to the English templates will need to be more carefully controlled, and we will need to, among other things, write a script to apply the translations to the master templates. Depending on how this can be implemented, this could be better than the proposal to use TMPL_VAR, because a gettext-based solution could take care of changes in word order. Of course, images cannot be translated this way; they still have to be manually created (or created with script-fu, if we decide to do that for certain languages). This still sounds like a big change (though definitely a welcome change if things work the way we intend them to work out); I don't know what to think of it. -- Ambrose LI Cheuk-Wing <a.c.li@ieee.org>
On Wed, 2003-01-29 at 21:22, Ambrose Li via forwarder wrote:
On Wed, 2003-01-29 at 19:36, Andrew Arensburger wrote: [stuff deleted]
No, what Andrew proposed is that we keep one set of master templates (the English ones), and a set of translation files. At buildrelease time (or install time), translated templates are generated by applying the translations to the master templates.
The advantage of this is that we separate theme from language, and make the list of strings to translate explicit. On the other hand, changes to the English templates will need to be more carefully controlled, and we will need to, among other things, write a script to apply the translations to the master templates.
Depending on how this can be implemented, this could be better than the proposal to use TMPL_VAR, because a gettext-based solution could take care of changes in word order.
Of course, images cannot be translated this way; they still have to be manually created (or created with script-fu, if we decide to do that for certain languages).
This still sounds like a big change (though definitely a welcome change if things work the way we intend them to work out); I don't know what to think of it.
OK I understand. I read it as doing the translation at install, not making the templates at install time. Thanks to everyone who responded and brought me up to speed. :-) Sorry for any false alarms. Micheas
Hi all, The perfect scenario would be to just have one set of template files for a theme, and the language strings other than english would be looked up from a "leksicon" file. There is something about it in the Locale:Maketext documentation but I am too small a brain to figure out what solution is waiting for us there to be applied. Also PGetText looks so simple, but again.... Benedict
OK I understand. I read it as doing the translation at install, not making the templates at install time.
Thanks to everyone who responded and brought me up to speed. :-)
Sorry for any false alarms.
Micheas
Hi everybody, I leave my computer for 2 days, and you begin a revolution :-) My thoughts : In french we have a little proverb that say "the Best may be the ennemy from the Good". That's the first thing I wanted to say : we need to release a stable version, so we have to stop improve koha one day ! Second proverb, well known from perl-mongers : "there's more than one way to do it". We could use gettext to translate koha. We even took a look at a XML parser tool with Chris iirc. We have MANY solutions to translate koha. But which is the best ??? none I think. * gettext : we can't have themes, and maybe get problems with non 8859-1 languages. I translated gnucash in French, which used gettext. That's not a "perfect" way to translate too imho ! * templates : we have to rewrite dozen of times the same word. * XML parser : i could'nt even install the tool :-(, too complicated for simple installs. * template+ <TMPL_VAR name="TEXT_xxx"> for some words : needs some benchmarks tests, but seems a nice idea (best from both worlds) So, I think : We made a choice some months ago, and this choice was not bad. Could be perfected thought ! Let's go to the 2.0 version with it, and let's see for 2.0.x if we can improve it ! Note : I remember everybody that our first wish is to satisfy LIBRARIANS. Programmer happyness is a little bit less important ! -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Benedict a écrit:
To me, a no programmer, it seems a disastrous move, to start an international effort to translate Koha in the way we do it today. Thank God "acli" modified my polish files for the changes he thought relevant. But Paul, who contributed a fantastic solution of text only include files did it only for the French version. Now, I don't complain he was egoistic. He had no choice, rather, because there was only a minor change he proposed. In my opinion, however, Paul's change was crucial for the future of Koha. He showed that the interface may be simple and very functional.... .
Note that if everybody agrees to say my solution is fantastic, i can commit it on /en/ too ! It's quite simple. In fact, i didnt' made it because i thought it was'nt as nice as katipo work. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (9)
-
Ambrose Li <acli＠ada.dhs.org> via forwarder -
Andrew Arensburger -
Benedict -
Chris Cormack -
Micheas Herman -
nicolas morin -
paul POULAIN -
Rachel Hamilton-Williams -
Tonnesen Steve