On 26 August 2017 at 16:21, Björn Persson <Bjorn@rombobjörn.se> wrote:
Tomasz Kłoczko wrote:
> This how it IMO should be done:
[..]
That looks like a good plan for how large numbers of translators can
contribute translations to many different languages.
Writing the translations directly in the spec doesn't scale well when
there are many languages and many translators, but it's very convenient
in the special case where the translator is also the package maintainer.
For the maintainer it would be much more trouble to edit the English
description, commit and push, wait for the translation system to get
updated, edit the translation in a different tool, and finally commit
and push again.
So to anyone who decides to implement Tomasz' proposal, please make it
work together with translations in the spec, not replace them.
Just two more thoughts:
1) As long as as sections with "%description [-n] <subpackage_name> -l <lang>" can be added in almost any place of the spec fie seems like it is some easy way about how to add all translations without touching original package spec files maintained in packages git repos.
In global macros is after include all macros can be added fragment like:
if [ %{_specdir}/%{name}.spec.i18n ]; then
%include %{_specdir}/%{name}.i18n
fi
standard %clean probably could be extended to remove this file after build if it will be injected to build process in exactly this directory.
IMO adding translations should be not a part of the standard rpm macros and should be present only in koji so above if with %include probably could be added in build account ~/.rpmrc. or by adding some new file in /usr/lib/rpm/macros.d/ or even add redefine %_spec_prep_pre in command line to add add %include.
2) Adding all Summary(<lang>) will be probably a bit more tricky.
To not touch original spec files probably best would be extend current Summary field syntax to something like:
Summary(<lang>,[[-n ]<package_name>]): <translates_summary>
This IMO more likely would allow to add on build stage dynamically all available translations transparently without bothering each packages maintainers.
kloczek
--
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
