Translation of SQL files
Hi Ricardo and all, At 13.11 29/07/2009, Ricardo Dias Marques wrote:
I think there should be only: - 1 (ONE) Unimarc Bibliographic SQL file - and 1 (ONE) Unimarc Authorites SQL file
... and NOT one of those for EACH language. The current situation, IMHO, leads to much Copy + Paste work, when one needs to create a new translation (both tiresome and error prone). Also, if there is one BUG in one language setup (SQL files) - like this requirement of an "Authority Type" called "PER" in the English one - we'll probably have to change all the other languages (SQL files) that were copied from that one, to correct that bug.
I think that the descriptions (for instance "liblibrarian" and "libopac" fields of the "marc_tag_structure" table) are the only fields that have to be translated. These fields could, for instance:
yes, the only fields to translate in Unimarc/MARC21 SQL files are liblibrarian and libopac. But how can we do the translation ? This is a problem that sometime appers in this list. I try to find a solution or an open source tool, but I never found a solution Bye Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)
Would it be possible to have the current translation process include the SQL files. Then it's just a matter of having the .po files parsed prior to packaging a release, and have the SQL files for other languages created that way. There would probably need to be a user defined function in the database for _(), as that is what the translation script watches for as I understand it. On Wed, 2009-07-29 at 15:12 +0200, Zeno Tajoli wrote:
Hi Ricardo and all,
yes, the only fields to translate in Unimarc/MARC21 SQL files are liblibrarian and libopac.
But how can we do the translation ? This is a problem that sometime appers in this list.
I try to find a solution or an open source tool, but I never found a solution
Bye
Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha
Translating SQL has a high likelihood of inducing unrecoverable error. The translation parser already just *barely* works as it is for HTML::Template::Pro files. I wouldn't trust it, or extending a custom tangle of code like it to handle a totally different language in files that are necessary to even begin installation. -- Joe Atzberger LibLime - Open Source Library Solutions On Wed, Jul 29, 2009 at 11:04 AM, Michael Hafen <mdhafen@tech.washk12.org>wrote:
Would it be possible to have the current translation process include the SQL files. Then it's just a matter of having the .po files parsed prior to packaging a release, and have the SQL files for other languages created that way.
There would probably need to be a user defined function in the database for _(), as that is what the translation script watches for as I understand it.
On Wed, 2009-07-29 at 15:12 +0200, Zeno Tajoli wrote:
Hi Ricardo and all,
yes, the only fields to translate in Unimarc/MARC21 SQL files are liblibrarian and libopac.
But how can we do the translation ? This is a problem that sometime appers in this list.
I try to find a solution or an open source tool, but I never found a solution
Bye
Zeno Tajoli
This is a good point. I would counter with my opinion that the templates are just as necessary to begin installation, but the point is still valid. The question becomes can the current translation process be easily extended to handling the SQL files separate from the parser? That would probably be the best way to go, and there certainly needs to be a separation of the frameworks from the description of the tag/subfields. Perhaps the best way would be to have just the two SQL files for the default frameworks, i.e. one for MARC21 and one for UNIMARC. Then have separate SQL files which are more translatable, which do SQL UPDATES. This way the current database structure could be used. On the other hand this creates a sort of system language. Where the template language can be changed by the user perhaps the MARC framework language should be too. This brings us back Ricardo's Option B. Have a separate table to hold different translations of the MARC framework. Then show the user which ever translation they have selected from this table. This would allow the MARC framework descriptions to follow the users selected language, but would require more complex code (probably in the SQL). Some food for thought anyway. On Wed, 2009-07-29 at 11:22 -0400, Joe Atzberger wrote:
Translating SQL has a high likelihood of inducing unrecoverable error.
The translation parser already just *barely* works as it is for HTML::Template::Pro files. I wouldn't trust it, or extending a custom tangle of code like it to handle a totally different language in files that are necessary to even begin installation.
-- Joe Atzberger LibLime - Open Source Library Solutions
On Wed, Jul 29, 2009 at 11:04 AM, Michael Hafen <mdhafen@tech.washk12.org> wrote: Would it be possible to have the current translation process include the SQL files. Then it's just a matter of having the .po files parsed prior to packaging a release, and have the SQL files for other languages created that way.
There would probably need to be a user defined function in the database for _(), as that is what the translation script watches for as I understand it.
On Wed, 2009-07-29 at 15:12 +0200, Zeno Tajoli wrote: > Hi Ricardo and all,
> yes, the only fields to translate in Unimarc/MARC21 SQL files > are liblibrarian and libopac. > > But how can we do the translation ? > This is a problem that sometime appers in this list. > > I try to find a solution or an open source tool, but I never found a solution > > Bye > > Zeno Tajoli
-- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha
participants (3)
-
Joe Atzberger -
Michael Hafen -
Zeno Tajoli