Ye Cheng: Looking for a sponsor/reintroduce myself

[Cheng Ye]

I am an inexperienced high school student interested in join packaging group. I have been
using Fedora Workstation as the primary OS on my desktop for four years and I want to give
something back to this free OS. I have some introductory knowledge about python and C++. I
am currently learning java in school, while I am always excited about trying new
language.
I have 2 approved packages:
bstrlib:https://bugzilla.redhat.com/show_bug.cgi?id=1476434
python-jieba: https://bugzilla.redhat.com/show_bug.cgi?id=1479280
By the way, the upstream of this package provides a Chinese translation of the summary and
translation. How to make these only visible to Chinese users?
I am currently working on cmu-ipc, but upstream is not very active:
https://bugzilla.redhat.com/show_bug.cgi?id=1481237

I also did two unofficial reviews:
https://bugzilla.redhat.com/show_bug.cgi?id=1439893 (sorry for pasting compiler warnings,
they are not necessary)
https://bugzilla.redhat.com/show_bug.cgi?id=1479022

Thanks,
Ye Cheng

Translations in an RPM spec (was: Ye Cheng: Looking for a sponsor/reintroduce myself)

[Björn Persson]

"Cheng Ye" <cheng__ye(a)126.com&gt; wrote:
>  By the way, the upstream of this package provides a Chinese
> translation of the summary and translation. How to make these only visible to Chinese
> users? 
You can include translations in the spec with "Summary(xx):" and
"%description -l xx", where "xx" is the language code. Here's a
spec
you can use as an example:

https://src.fedoraproject.org/rpms/python-sphinxcontrib-adadomain/raw/mas...

Björn Persson

Translations in an RPM spec (was: Ye Cheng: Looking for a sponsor/reintroduce myself)

[Tomasz Kłoczko]

On 25 August 2017 at 17:57, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; wrote:

>  "Cheng Ye" <cheng__ye(a)126.com&gt; wrote:
>  > By the way, the upstream of this package provides a Chinese translation
>  of the summary and translation. How to make these only visible to Chinese
>  users?
>
>  You can include translations in the spec with "Summary(xx):" and
>  "%description -l xx", where "xx" is the language code. Here's a
> spec
>  you can use as an example:
>
>  https://src.fedoraproject.org/rpms/python-sphinxcontrib-adad
>  omain/raw/master/f/python-sphinxcontrib-adadomain.spec 

Problem with placing straight translations in spec files is that if someone
will change something in original English Summary firld or %description
without manual intervention other languages translators will never now that
that something needs to be updated.
This is why in the past was used specpo which allowed to extract all
strings to translate in i18n .po file. Such file has ability to mark
strings which needs to be reviewed to update translations. specpo package
have been holding whole distribution all packages translations to different
languages in separated .mo files and whole size of the specpo package was
huge.

Both methods are somehow bad.
First one placing translations straight in spec files makes translations
unmanageable after any changes of original description.
Second by holding centrally all translations outside each packages have
been making those translations hard to scale with list of installed
packages and used languages. As well any changes in any translations or
adding new packages theoretically should trigger release new version of the
specpo package.

In the past I had better idea how to solve all those problems however I
never had time to implement those ideas.

This how it IMO should be done:

1) every release of the package to git repos should automatically pass them
over filters extracting strings which needs to be translated.

2) all phrases which needs to be translated should be hold in i18n .po
files as reference allowing to figure out that some of the already
translated phrases needs to be updated. All those strings should be
available probably over web frontend forming lists strings which needs to
be updated or still are without initial translations. Changes in .po could
be kept in VCS repo to tracka all changes

3) on build time packages all %descriptions and Summary fields needs to be
extracted and queried against reference .po files and on just assembly
binary packages all possible other languages should be added.

All this above process would allow on package install time choose which one
languages should be copied to rpm database by checking "%_install_langs
<list:of:langs>" which can be added to /etc/rpm/rpmrc (BTW .. aal this is
already supported from +10 years) on package install/upgrade time
completely transparently.
This will allow as well separate well translators job and glue thy work
just right on place to each package without.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH

Translations in an RPM spec (was: Ye Cheng: Looking for a sponsor/reintroduce myself)

[Tomasz Kłoczko]

On 25 August 2017 at 17:57, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; wrote:

>  "Cheng Ye" <cheng__ye(a)126.com&gt; wrote:
>  > By the way, the upstream of this package provides a Chinese translation
>  of the summary and translation. How to make these only visible to Chinese
>  users?
>
>  You can include translations in the spec with "Summary(xx):" and
>  "%description -l xx", where "xx" is the language code. Here's a
> spec
>  you can use as an example:
>
>  https://src.fedoraproject.org/rpms/python-sphinxcontrib-
>  adadomain/raw/master/f/python-sphinxcontrib-adadomain.spec 

Problem with keeping translations in spec files is that if someone will
change something in original English Summary firld or %description without
manual intervention other languages translators will never now that that
something needs to be updated.
This is why in the past was used specpo which allowed to extract all
strings to translate in i18n .po file. Such file has ability to mark
strings which needs to be reviewed to update translations. specpo package
have been holding whole distribution all packages translations to different
languages in separated .mo files and whole size of the specpo package was
huge.

Both methods are somehow bad.
First one placing translations straight in spec files makes translations
unmanageable after any changes of original description.
Second by holding centrally all translations outside each packages have
been making those translations hard to scale with list of installed
packages and used languages. As well any changes in any translations or
adding new packages theoretically should trigger release new version of the
specpo package.

In the past I had better idea how to solve all those problems however I
never had time to implement those ideas.

This how it IMO should be done:

1) every release of the package to git repos should automatically pass them
over filters extracting strings which needs to be translated.

2) all phrases which needs to be translated should be hold in i18n .po
files as reference allowing to figure out that some of the already
translated phrases needs to be updated. All those strings should be
available probably over web frontend forming lists strings which needs to
be updated or still are without initial translations. Changes in .po could
be kept in VCS repo to tracka all changes

3) on build time packages all %descriptions and Summary fields needs to be
extracted and queried against reference .po files and on just assembly
binary packages all possible other languages should be added.

All this above process would allow on package install time choose which one
languages should be copied to rpm database by checking "%_install_langs
<list:of:lngs>" which can be added to /etc/rpm/rpmrc (BTW .. aal this is
already supported from +10 years) on package install/upgrade time
completely transparently.
This will allow as well separate well translators job and glue thy work
just right on place to each package without.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*

Translations in an RPM spec

[Björn Persson]

Tomasz Kłoczko wrote:
>  This how it IMO should be done:
>  
>  1) every release of the package to git repos should automatically
>  pass them over filters extracting strings which needs to be
>  translated.
>  
>  2) all phrases which needs to be translated should be hold in i18n .po
>  files as reference allowing to figure out that some of the already
>  translated phrases needs to be updated. All those strings should be
>  available probably over web frontend forming lists strings which
>  needs to be updated or still are without initial translations.
>  Changes in .po could be kept in VCS repo to tracka all changes
>  
>  3) on build time packages all %descriptions and Summary fields needs
>  to be extracted and queried against reference .po files and on just
>  assembly binary packages all possible other languages should be added. 
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.

Björn Persson

Translations in an RPM spec

[Tomasz Kłoczko]

On 26 August 2017 at 16:21, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se&gt; 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
--

[Robert-André Mauchin]

Le vendredi 25 août 2017 à 15:04:52 (-0000), Cheng Ye a écrit :
>  By the way, the upstream of this package provides a Chinese
> translation of the summary and translation. How to make these only visible to Chinese
> users?
>  
You should be able to add a summary for zh_CN (or zh or zh_TW, just choose the
correct locale) like this:

Summary(zh_CN):    The summary in Chinese

And for the description:

%description -l zh_CN
The description in Chinese


Best regards,

Robert-André