On 25 August 2017 at 17:57, Björn Persson <Bjorn@rombobjörn.se> wrote:
"Cheng Ye" <cheng__ye@xxxxxxx> 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
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
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
