https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25067 --- Comment #36 from Julian Maurice <julian.maurice@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.