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

[Jens-Ulrik Petersen]

Hi,

yum-langpacks has been working pretty well now for a while in Fedora,
but all langpacks are still listed conditionally in comps' language support groups
in addition to the <langpacks> meta-section.

So for F17 I'd like to remove them all from comps,
this will simplify comps a lot and if we can also
remove the resulting empty language support groups
it will also reduce the comps translation burden
in addition to comps maintenance.

A few things I noted while attempting to prune comps-f17:

- most of the remaining packages in language support group are fonts and input-methods
  - perhaps the mandatory/default ones could Provide: fonts(lang) and input-method(lang).
- normal anaconda installs support installation of multiple language support groups
  - I think it would be better to move the list of languages out of comps into anaconda
itself
    (they are already translated in iso-codes, etc)
  - anaconda could then set langpack_locales to install langpacks for multiple languages
- we maybe need to add a new "yum install-lang" command say to replace "yum
install @<lang>-support"
  which could use a more aggressive version of yum-langpacks to pull the required
packages.
- @base and @office still list aspell-en, hunspell-en, and libreoffice-langpack-en
conditionally
  which I think could be dropped.

Anyway the fact that we can remove 1500 basically redundant lines now
from comps thanks to Bill's great work on yum-langpacks is good news and
would be a big win IMHO.  This might well make a good F17 Feature.

Jens

[Ankit Patel]

On 09/09/2011 10:50 AM, Jens Petersen wrote:
>  Hi,
>
>  yum-langpacks has been working pretty well now for a while in Fedora,
>  but all langpacks are still listed conditionally in comps' language support groups
>  in addition to the<langpacks>  meta-section.
>
>  So for F17 I'd like to remove them all from comps,
>  this will simplify comps a lot and if we can also
>  remove the resulting empty language support groups
>  it will also reduce the comps translation burden
>  in addition to comps maintenance.
>
>  A few things I noted while attempting to prune comps-f17:
>
>  - most of the remaining packages in language support group are fonts and input-methods
>     - perhaps the mandatory/default ones could Provide: fonts(lang) and
> input-method(lang).
>  - normal anaconda installs support installation of multiple language support groups
>     - I think it would be better to move the list of languages out of comps into anaconda
> itself
>       (they are already translated in iso-codes, etc)
>     - anaconda could then set langpack_locales to install langpacks for multiple
> languages
>  - we maybe need to add a new "yum install-lang" command say to replace
> "yum install @<lang>-support"
>     which could use a more aggressive version of yum-langpacks to pull the required
> packages.
>  - @base and @office still list aspell-en, hunspell-en, and libreoffice-langpack-en
> conditionally
>     which I think could be dropped.
>
>  Anyway the fact that we can remove 1500 basically redundant lines now
>  from comps thanks to Bill's great work on yum-langpacks is good news and
>  would be a big win IMHO.  This might well make a good F17 Feature.
>
>  Jens 
Hi,

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?

Anybody knows, how to modify the path of message catalogs (i.e.
/usr/share/locale) dynamically while running an application? I would
like to use a different mo file rather than the default provided by
system. Is it possible? If yes, how?

Thanks!
-- 
Regards,
Ankit Patel
http://www.ankit644.com/

[Yuri Chornoivan]

написане Fri, 09 Sep 2011 09:50:43 +0300, Ankitkumar Rameshchandra Patel  
<ankit(a)redhat.com&gt;:

>  Anybody knows, how to modify the path of message catalogs (i.e.
>  /usr/share/locale) dynamically while running an application? I would
>  like to use a different mo file rather than the default provided by
>  system. Is it possible? If yes, how? 
In KDE, translator can compile the translation to  
~.kde/share/locale/xx/LC_MESSAGES (preferred over /usr/share/locale)  
directly from Lokalize interface (Tools -> Install translation locally).  
But it works only for KDE translations.

I am afraid this approach cannot be used generally.

Dynamical changes in gettext catalogs likely immediately crash the  
application.

[Dimitris Glezos]

On Fri, Sep 9, 2011 at 9:50 AM, Ankitkumar Rameshchandra Patel
<ankit(a)redhat.com&gt; 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.

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).

- Need to take extra care to avoid having a new langpack shipped to a user
  every day, since for some countries this might cause issues).

Hope this helps.

-d



-- 
Dimitris Glezos

Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/

[Piotr Drąg]

2011/9/9 Ankitkumar Rameshchandra Patel <ankit(a)redhat.com&gt;:
>  Related note. How about we also change the way we manage
> translations
>  for packages?
>
>  Shouldn't we have translations packaged independently from RPM packages?
>  
Please don't do it. We had this discussion a couple of times already.
It's not worth it, it most probably won't work.

-- 
Piotr Drąg
http://raven.fedorapeople.org/

[Cheng-Chia Tseng]

I think that it at least has one advantage.

For example, we can deliver new translatins more frequently, while the
package does not plan to issue newer releases in that period.

On Sat, Sep 10, 2011 at 3:44 AM, Piotr Drąg <piotrdrag(a)gmail.com&gt; wrote:
>  2011/9/9 Ankitkumar Rameshchandra Patel <ankit(a)redhat.com&gt;:
> > Related note. How about we also change the way we manage translations
> > for packages?
> >
> > Shouldn't we have translations packaged independently from RPM packages?
> >
>
>  Please don't do it. We had this discussion a couple of times already.
>  It's not worth it, it most probably won't work.
>
>  --
>  Piotr Drąg
>  http://raven.fedorapeople.org/
>  --
>  trans mailing list
>  trans(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/trans 


-- 
Sincerely,
by Cheng-Chia Tseng

[Domingo Becker]

2011/9/9 Dimitris Glezos <glezos(a)indifex.com&gt;:
>  On Fri, Sep 9, 2011 at 9:50 AM, Ankitkumar Rameshchandra Patel
>  <ankit(a)redhat.com&gt; 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

[Ankit Patel]

On 09/10/2011 08:33 PM, Cheng-Chia Tseng wrote:
>  I think that it at least has one advantage.
>
>  For example, we can deliver new translatins more frequently, while the
>  package does not plan to issue newer releases in that period.
>
>  On Sat, Sep 10, 2011 at 3:44 AM, Piotr Drąg<piotrdrag(a)gmail.com>  wrote:
> > 2011/9/9 Ankitkumar Rameshchandra Patel<ankit(a)redhat.com>:
> >> Related note. How about we also change the way we manage translations
> >> for packages?
> >>
> >> Shouldn't we have translations packaged independently from RPM packages?
> >>
> >
> > Please don't do it. We had this discussion a couple of times already.
> > It's not worth it, it most probably won't work.
> >
> > --
> > Piotr Drąg
> > http://raven.fedorapeople.org/
> > --
> > trans mailing list
> > trans(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/trans
>
>
>  
In short, translators will have greater control over their translations
and developers will have less burden of dealing with translations.

To know more about advantages and the thread:
http://lists.fedoraproject.org/pipermail/devel/2011-September/156674.html

/Ankit

-- 
Regards,
Ankit Patel
http://www.ankit644.com/

[Ankit Patel]

On 09/09/2011 09:10 PM, Yuri Chornoivan wrote:
>  написане Fri, 09 Sep 2011 09:50:43 +0300, Ankitkumar Rameshchandra
> Patel
>  <ankit(a)redhat.com&gt;:
>
> > Anybody knows, how to modify the path of message catalogs (i.e.
> > /usr/share/locale) dynamically while running an application? I would
> > like to use a different mo file rather than the default provided by
> > system. Is it possible? If yes, how?
>
>  In KDE, translator can compile the translation to
>  ~.kde/share/locale/xx/LC_MESSAGES (preferred over /usr/share/locale)
>  directly from Lokalize interface (Tools ->  Install translation locally).
>  But it works only for KDE translations.
>
>  I am afraid this approach cannot be used generally.
>
>  Dynamical changes in gettext catalogs likely immediately crash the
>  application. 

How can we achieve such solution for Gnome and Fedora applications too?
Any pointers?

Thanks!
-- 
Regards,
Ankit Patel
http://www.ankit644.com/

[Dimitris Glezos]

On Mon, Sep 12, 2011 at 8:42 AM, Ankitkumar Rameshchandra Patel
<ankit(a)redhat.com&gt; wrote:
>  In short, translators will have greater control over their
> translations
>  and developers will have less burden of dealing with translations.
>
>  To know more about advantages and the thread:
>  http://lists.fedoraproject.org/pipermail/devel/2011-September/156674.html 
If you'd like to push this, I suggest to treat this like any other
fedora feature.

  http://fedoraproject.org/wiki/Features/Policy

It will probably need a couple of engineers who has genuine interest
in establishing and maintaining this support, interacting with the
developers & performing the packaging, and also some work in the L10n
side of things.

-d



-- 
Dimitris Glezos

Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/

[Noriko Mizumoto]

(2011年09月12日 16:57), Dimitris Glezos wrote:
>  On Mon, Sep 12, 2011 at 8:42 AM, Ankitkumar Rameshchandra Patel
>  <ankit(a)redhat.com&gt;  wrote:
> > In short, translators will have greater control over their translations
> > and developers will have less burden of dealing with translations.
> >
> > To know more about advantages and the thread:
> > http://lists.fedoraproject.org/pipermail/devel/2011-September/156674.html
>  If you'd like to push this, I suggest to treat this like any other
>  fedora feature. 
I have a couple of questions.

It says as advantage;
"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."

* A couple of lang packs, which lang packs to be included and why others 
not?
* In order to obtain language packs, do users need internet connection 
for downloading?

It says as possible drawback;
"Need to take extra care to avoid having a new langpack shipped to a 
user every day"

* What is specific solution implemented?


noriko

>     http://fedoraproject.org/wiki/Features/Policy
>
>  It will probably need a couple of engineers who has genuine interest
>  in establishing and maintaining this support, interacting with the
>  developers&  performing the packaging, and also some work in the L10n
>  side of things.
>
>  -d
>
>
>