comps headsup: plan to drop langpacks from language-support groups in comps-f17.xml.in

[Domingo Becker]

2011/9/9 Dimitris Glezos <glezos at indifex.com>:
> On Fri, Sep 9, 2011 at 9:50 AM, Ankitkumar Rameshchandra Patel
> <ankit at redhat.com> wrote:
>> Related note. How about we also change the way we manage translations
>> for packages?
>>
>> This gives more control over translations to translators also
>> translators become independent from package maintainers and can reduce
>> burden from package maintainers taking care of translations!
>>
>> Shouldn't we have translations packaged independently from RPM packages?
>
> This is indeed possible. We did this in MeeGo and worked quite well. Here's the
> workflow we already implemented with MeeGo:
>
>  1. Developer has neither POT or PO files in git. No need to.
>  2. Developer builds his package. His Makefile produces the POT on-the-fly and
>    includes it in the RPM.
>  3. Developer pushes his SRPM on build system. His SRPM contains one POT file
>    and no PO files.
>  4. Transifex Middleware App monitors the build system for updates on packages.
>    It detects a new version of the Anaconda SRPM. It downloads it, extracts
>    the POT file from inside and pushes it to Transifex.
>  5. Transifex imports the file and notifies all translators if there are new
>    strings available.
>  6. Translators provide translations either offline or online.
>  7. Localization packager uses Transifex client to pull all translations for
>    eg. F17 and push a update on the language packs. LPacks are splitted eg. as
>    fedora-langpack-ui-pt_BR etc.
>  8. User sees an update on yum and installs it.
>
> Advantages:
>
> - Developer is isolated from the need to host translations -- less clutter in
>  his repo and changelog.
> - Developer does not need to remember to update his POT and pull translations,
>  often forgotten (eg. the "pull fresh translations after deadline).
> - L10n packager and language teams can push updates to their language any time
>  they want.
> - CD/DVD can include only a couple of lang packs, so smaller size. Upon
>  selection of the language, yum (or even the installer) can download the lang
>  pack right away.
> - Process works well with release cycles, since there is a string freeze
>  period.
>

It seems promising.

+1

Is there any package we can test it with?


> Possible drawbacks:
>
> - During Updates cycles (after a release is shipped): Between the time the
>  developer pushes his package and the time the lang packs are updated, the
>  user may see a couple of English strings on his UI. This happens also when
>  the developer hosts his PO files, unless he decides to have small
>  string-freezes every time (don't know anyone who does this).
>

It's not a problem.
It will encourage translators participation.

kind regards

Domingo Becker