[Koha-bugs] [Bug 25067] Move PO file manipulation code into gulp tasks

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25067

--- Comment #36 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to Katrin Fischer from comment #34)
> I don't know about the .pot files, but was looking at the test plan again
> (thx for the write-up!):
> 
> - Can 'gulp po:update' be run for a selected language? It takes a long while
> to do this for all languages, so you might want to do it only for the ones
> you need/test with.
Yep, just use --lang option:

  gulp po:update --lang de-DE

> You write:
> >- there is no need for $KOHA_CONF to be defined
> >  LangInstaller.pm relied on $KOHA_CONF to get the different paths
> >  needed. I'm not sure why, since string extraction and PO update should
> >  work on source files, not installed files
> 
> But aren't the paths to the templates we need to parse different depending
> on installation type? And also the po files will be stored in a different
> place?
I believe create and update operations should work exclusively on source files.
I don't see why we would want to work on the copy installed under
/usr/share/koha for instance.
Note that 'install' operation still work the same, translated templates are
installed in the right place.

> 
> We need to keep the option for everyone to update/install their own adapted
> po files. I know a lot of people make local changes. Even we do to a certain
> extend to have our own XSLT files translated.
We do too, but local translations are handled in separate PO files.

Do you alter the original PO files ? How do you handle Koha upgrades ?

> 
> Still a bit worried about this one:
> 
> >  Now context is put into msgctxt, and the reference is set, which is
> >  cleaner
> 
> >    #: koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/accounting.pref
> >    msgctxt "Accounting > Policy > FinePaymentAutoPopup"
> >    msgid "automatically display a print dialog for a payment receipt "
> >    "when making a payment.."
> 
> I think in translation practice using Pootle this could be quite hard on
> tranlators. :(
> 
> Right now you can search in the prefs file for a system preference and it
> will turn up all strings related to it. They also appear in alphabetic
> order, so when you start translating, you have the 'context' because the
> strings appear together with the prefixed note. This was intentional and a
> 'feature'. 
> 
> It doesn't seem that we can search by 'context' in Pootle, so seeing all
> strings for a pref together will no longer be possible.
It seems that Pootle can search by comment. Would that help if the syspref name
and category appear in a comment ?

> 
> To explain: Translating prefs is quite hard because you have to make sure
> things work grammatically with sentence parts torn apart. This depends on
> language I am sure, but for German it's not an easy task and we can't
> translate "Do" and "Don't" just like that. Often we need to move parts of
> the rest of the sentence into the options for things to make more sense.
This will still be possible

> 
> Also:
> 
> >  The downside is that some messages will have to be re-translated,
> >  especially short messages like 'Do', for which msgmerge has a hard
> >  time finding the corresponding new msgid.
> 
> This is quite a burden for translators, escpecially since you have to look
> up every single one of them to see what the rest of the sentence looks like.
> Can't we figure them out? We do have the pref and the current translation.
Probably.
We can also easily revert this change from this patchset and address the issue
in a separate bug. This bug brings already too many different things, so if it
helps I will gladly remove that. I just thought it would be a nice "clean up"
to do at the same time.

(In reply to Katrin Fischer from comment #35)
> > - In the test plan only installing a language is used with the old syntax,
> > creating and updating are different. I think mixing would not be good. Why
> > is it not possible to move all to the old syntax? and should we them move
> > installing as well with the deprecation note you suggest?
> 
> Realizing that last bit made no sense:
> 
> And should we not move installing to the new syntax as well with a
> deprecation note like you suggest? 
> 
> Overall I think we need to keep things as easy as possible since not only
> experienced Koha users will be using these commands (update, install,
> create).
In my opinion, install is really different from create/update so it makes sense
for it to be in a different script/called in a different way.
Only install should be called by end users (people who manage Koha instances)
create/update is more for Koha translation maintainer (aka Bernardo)

-- 
You are receiving this mail because:
You are watching all bug changes.