https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25067
--- Comment #36 from Julian Maurice <julian.maur...@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. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/