Hi all, While I mostly work in English, I occasionally do support libraries in other languages like French, Arabic, and Chinese. And more recently Ive been looking at the Languages dropdown in the OPAC advanced search. In the templates, I notice that we often translate HTML, but what if we translated strings for a Template::Toolkit data structure instead? Consider the following: [% BLOCK en %]Anglais[% END %] [% BLOCK fr %]Français[% END %] [% langs.en = INCLUDE en %] [% langs.fr = INCLUDE fr %] I suppose its not very beautiful, but the translation process should be simple and in the end we have a re-usable hash map rather than static HTML. As I commented on Bug 12017 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017), we could have a database table of language codes with native language names, and then iterate through that and use the hash map of translations to provide the translations. Since were not producing HTML, we could flexibly reuse this language data in various different contexts. Whether its the Languages dropdown in the OPAC advanced search, the language selector, or whatever. We could probably use this concept in other places as well where we need translations but we dont want to be bound to HTML. What do people think? Im not wedded to the idea, but its something that crossed my mind this morning, when I looked at the large switch statements at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=120 17&attachment=40285> &bug=12017&attachment=40285. (To that end, I would also suggest a theme-independent Template::Toolkit include directory, but thats another story ) David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595
Hi David, I think that language descriptions would be best in a Perl module, so that they can be used everywhere (perl and templates). For instance: package Koha::Languages; use Koha::I18N; sub getLanguages { return { en => __('English'), fr => __('French'), } } And if the original description is needed, we can do the same but without the __() translation. sub getLanguagesDescriptionsInTheirOwnLanguage { return { en => 'English', fr => 'Français', } } Le 26/04/2021 à 02:44, dcook@prosentient.com.au a écrit :
Hi all,
While I mostly work in English, I occasionally do support libraries in other languages like French, Arabic, and Chinese. And more recently I’ve been looking at the Languages dropdown in the OPAC advanced search.
In the templates, I notice that we often translate HTML, but what if we translated strings for a Template::Toolkit data structure instead?
Consider the following:
[% BLOCK en %]Anglais[% END %]
[% BLOCK fr %]Français[% END %]
[% langs.en = INCLUDE en %]
[% langs.fr = INCLUDE fr %]
I suppose it’s not very beautiful, but the translation process should be simple and in the end we have a re-usable hash map rather than static HTML.
As I commented on Bug 12017 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017>), we could have a database table of language codes with native language names, and then iterate through that and use the hash map of translations to provide the translations. Since we’re not producing HTML, we could flexibly reuse this language data in various different contexts. Whether it’s the Languages dropdown in the OPAC advanced search, the language selector, or whatever.
We could probably use this concept in other places as well where we need translations but we don’t want to be bound to HTML.
What do people think? I’m not wedded to the idea, but it’s something that crossed my mind this morning, when I looked at the large switch statements at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=12017&attachment=40285 <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=12017&attachment=40285>.
(To that end, I would also suggest a theme-independent Template::Toolkit include directory, but that’s another story…)
David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Julian Maurice BibLibre
Hi Julian, I like part of what you've suggested here. I still think that putting languages (with codes and name in native text) in the database is a good idea, as it allows the ability to add languages to Koha without a code change. Unless Koha is going to be perfectly comprehensive with languages, I think that libraries need to be able to add their own languages to the database. But I'd be fine with putting the translations of languages into Perl rather than Template::Toolkit. I've found the barrier to entry for Koha translations to be too high, so I can't keep track of all the different _(), __(), _t(), etc functions across the different file types, but if your suggestion for Koha::Languages works using that __() syntax, then I'm fine with it. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Julian Maurice Sent: Monday, 26 April 2021 8:17 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Template::Toolkit and Translations Hi David, I think that language descriptions would be best in a Perl module, so that they can be used everywhere (perl and templates). For instance: package Koha::Languages; use Koha::I18N; sub getLanguages { return { en => __('English'), fr => __('French'), } } And if the original description is needed, we can do the same but without the __() translation. sub getLanguagesDescriptionsInTheirOwnLanguage { return { en => 'English', fr => 'Français', } } Le 26/04/2021 à 02:44, dcook@prosentient.com.au a écrit :
Hi all,
While I mostly work in English, I occasionally do support libraries in other languages like French, Arabic, and Chinese. And more recently I’ve been looking at the Languages dropdown in the OPAC advanced search.
In the templates, I notice that we often translate HTML, but what if we translated strings for a Template::Toolkit data structure instead?
Consider the following:
[% BLOCK en %]Anglais[% END %]
[% BLOCK fr %]Français[% END %]
[% langs.en = INCLUDE en %]
[% langs.fr = INCLUDE fr %]
I suppose it’s not very beautiful, but the translation process should be simple and in the end we have a re-usable hash map rather than static HTML.
As I commented on Bug 12017 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017>), we could have a database table of language codes with native language names, and then iterate through that and use the hash map of translations to provide the translations. Since we’re not producing HTML, we could flexibly reuse this language data in various different contexts. Whether it’s the Languages dropdown in the OPAC advanced search, the language selector, or whatever.
We could probably use this concept in other places as well where we need translations but we don’t want to be bound to HTML.
What do people think? I’m not wedded to the idea, but it’s something that crossed my mind this morning, when I looked at the large switch statements at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bu g=12017&attachment=40285 <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=12017&attachment=40285>.
(To that end, I would also suggest a theme-independent Template::Toolkit include directory, but that’s another story…)
David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
About the different translation functions, here's a tip: just remember "__npx" where each letter is an optional flag n for Numbers (plural forms) p for Particular context x for eXtra variables And in templates, where functions starting with '_' are considered private, the '__' prefix was replaced by 't' (but maybe we should use the 't' form everywhere to remove confusion ?) Also you can refer to https://git.koha-community.org/Koha-community/Koha/src/branch/master/docs/de... About database VS hardcoded list, what about a hardcoded but extensible list ? For instance you'd have the full ISO-639-* lists hardcoded in Perl, but it would be extensible, either by adding entries to the database, or by plugins. Le 27/04/2021 à 01:44, dcook@prosentient.com.au a écrit :
Hi Julian,
I like part of what you've suggested here. I still think that putting languages (with codes and name in native text) in the database is a good idea, as it allows the ability to add languages to Koha without a code change. Unless Koha is going to be perfectly comprehensive with languages, I think that libraries need to be able to add their own languages to the database.
But I'd be fine with putting the translations of languages into Perl rather than Template::Toolkit.
I've found the barrier to entry for Koha translations to be too high, so I can't keep track of all the different _(), __(), _t(), etc functions across the different file types, but if your suggestion for Koha::Languages works using that __() syntax, then I'm fine with it.
David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia
Office: 02 9212 0899 Online: 02 8005 0595
-----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Julian Maurice Sent: Monday, 26 April 2021 8:17 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Template::Toolkit and Translations
Hi David,
I think that language descriptions would be best in a Perl module, so that they can be used everywhere (perl and templates).
For instance:
package Koha::Languages; use Koha::I18N; sub getLanguages { return { en => __('English'), fr => __('French'), } }
And if the original description is needed, we can do the same but without the __() translation.
sub getLanguagesDescriptionsInTheirOwnLanguage { return { en => 'English', fr => 'Français', } }
Le 26/04/2021 à 02:44, dcook@prosentient.com.au a écrit :
Hi all,
While I mostly work in English, I occasionally do support libraries in other languages like French, Arabic, and Chinese. And more recently I’ve been looking at the Languages dropdown in the OPAC advanced search.
In the templates, I notice that we often translate HTML, but what if we translated strings for a Template::Toolkit data structure instead?
Consider the following:
[% BLOCK en %]Anglais[% END %]
[% BLOCK fr %]Français[% END %]
[% langs.en = INCLUDE en %]
[% langs.fr = INCLUDE fr %]
I suppose it’s not very beautiful, but the translation process should be simple and in the end we have a re-usable hash map rather than static HTML.
As I commented on Bug 12017 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017>), we could have a database table of language codes with native language names, and then iterate through that and use the hash map of translations to provide the translations. Since we’re not producing HTML, we could flexibly reuse this language data in various different contexts. Whether it’s the Languages dropdown in the OPAC advanced search, the language selector, or whatever.
We could probably use this concept in other places as well where we need translations but we don’t want to be bound to HTML.
What do people think? I’m not wedded to the idea, but it’s something that crossed my mind this morning, when I looked at the large switch statements at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bu g=12017&attachment=40285 <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=12017&attachment=40285>.
(To that end, I would also suggest a theme-independent Template::Toolkit include directory, but that’s another story…)
David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Julian Maurice BibLibre
I think I'll leave the internationalization to folk who can remember it better than me. As for lists... the key thing is supplying the full ISO 639-2 (or MARC Code List for Languages) to Koha, since that's what is being used to populate the bibliographic records. David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Julian Maurice <julian.maurice@biblibre.com> Sent: Tuesday, 27 April 2021 5:44 PM To: dcook@prosentient.com.au; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Template::Toolkit and Translations About the different translation functions, here's a tip: just remember "__npx" where each letter is an optional flag n for Numbers (plural forms) p for Particular context x for eXtra variables And in templates, where functions starting with '_' are considered private, the '__' prefix was replaced by 't' (but maybe we should use the 't' form everywhere to remove confusion ?) Also you can refer to https://git.koha-community.org/Koha-community/Koha/src/branch/master/docs/de... About database VS hardcoded list, what about a hardcoded but extensible list ? For instance you'd have the full ISO-639-* lists hardcoded in Perl, but it would be extensible, either by adding entries to the database, or by plugins. Le 27/04/2021 à 01:44, dcook@prosentient.com.au a écrit :
Hi Julian,
I like part of what you've suggested here. I still think that putting languages (with codes and name in native text) in the database is a good idea, as it allows the ability to add languages to Koha without a code change. Unless Koha is going to be perfectly comprehensive with languages, I think that libraries need to be able to add their own languages to the database.
But I'd be fine with putting the translations of languages into Perl rather than Template::Toolkit.
I've found the barrier to entry for Koha translations to be too high, so I can't keep track of all the different _(), __(), _t(), etc functions across the different file types, but if your suggestion for Koha::Languages works using that __() syntax, then I'm fine with it.
David Cook Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia
Office: 02 9212 0899 Online: 02 8005 0595
-----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Julian Maurice Sent: Monday, 26 April 2021 8:17 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Template::Toolkit and Translations
Hi David,
I think that language descriptions would be best in a Perl module, so that they can be used everywhere (perl and templates).
For instance:
package Koha::Languages; use Koha::I18N; sub getLanguages { return { en => __('English'), fr => __('French'), } }
And if the original description is needed, we can do the same but without the __() translation.
sub getLanguagesDescriptionsInTheirOwnLanguage { return { en => 'English', fr => 'Français', } }
Le 26/04/2021 à 02:44, dcook@prosentient.com.au a écrit :
Hi all,
While I mostly work in English, I occasionally do support libraries in other languages like French, Arabic, and Chinese. And more recently I’ve been looking at the Languages dropdown in the OPAC advanced search.
In the templates, I notice that we often translate HTML, but what if we translated strings for a Template::Toolkit data structure instead?
Consider the following:
[% BLOCK en %]Anglais[% END %]
[% BLOCK fr %]Français[% END %]
[% langs.en = INCLUDE en %]
[% langs.fr = INCLUDE fr %]
I suppose it’s not very beautiful, but the translation process should be simple and in the end we have a re-usable hash map rather than static HTML.
As I commented on Bug 12017 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12017>), we could have a database table of language codes with native language names, and then iterate through that and use the hash map of translations to provide the translations. Since we’re not producing HTML, we could flexibly reuse this language data in various different contexts. Whether it’s the Languages dropdown in the OPAC advanced search, the language selector, or whatever.
We could probably use this concept in other places as well where we need translations but we don’t want to be bound to HTML.
What do people think? I’m not wedded to the idea, but it’s something that crossed my mind this morning, when I looked at the large switch statements at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&b u g=12017&attachment=40285 <https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=12017&attachment=40285>.
(To that end, I would also suggest a theme-independent Template::Toolkit include directory, but that’s another story…)
David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Julian Maurice BibLibre
participants (2)
-
dcook＠prosentient.com.au -
Julian Maurice