Re: Plan for L10n for Fedora 11

[Asgeir Frimannsson]

----- "Dimitris Glezos" <dimitris(a)glezos.com&gt; wrote:
>  I'm very happy to announce that we've now landed support for
>  translation
>  statistics in Transifex.
>  
>  Lately we've been working heavily in re-writing Transifex and getting
>  v0.5 in
>  the best shape possible for Fedora 11. Being 3 weeks ahead of the
>  string
>  freeze, we have plenty of time to test statistics on Transifex
>  0.5-devel.
>  
>  For Fedora 11, my plan is to switch the old DL for Tx 0.5-devel for
>  statistics, and continue to use the proven Tx 0.3 for submissions.
>  I've
>  requested [1] a publictest instance from the Infrastructure Group to
>  install
>  it and start putting data and testing it.
>  
>    [1]: https://fedorahosted.org/fedora-infrastructure/ticket/1191
>  
>  To allow 2 weeks of testing, the instance should be ready by 23/2.
>  When we
>  see that everything works out as it should, we can discontinue the old
>  DL.
>  
>  Our goal with Transifex 0.5 is to include support for both submissions
>  and
>  statistics, and this way we can put aside our old version of Damned
>  Lies which
>  is presenting outdated translations. Since only the commits are
>  missing from
>  Tx 0.5-final, it'll be out in 3-4 weeks, and at that point we go on
>  and test
>  submissions too, while having Tx 0.3 as a backup solution.
>  
>  Some of the advantages of this approach is that using the statistics
>  from Tx
>  0.5-devel does not even require hook-up with FAS (only submissions
>  require
>  authentication), we have a smoother upgrade path for Django/v0.5 and
>  we have a
>  codebase we know inside-out to build/invest on. 
First of all, setting up a test-instance of Transifex 0.5alpha is a good start, so a big
+1 from me. You should probably think of a migration script for transferring the data as
well. I would suggest [1] as a good starting point for this, as it is based on Django and
gets you quickly up and running.

That said, I have a number of concerns with this approach. Just a few weeks back you noted
that 0.5 wouldn't be ready in time for F11, and that a good approach would be to
migrate to the new Django-based Damned Lies for F11. Hence, I have spent roughly a week
worth of development on this now, and I am announcing a public test period for this by the
end of this week. The changes we have made to the upstream Gnome version include
Fedora-theming (similar to the existing instance), FAS authentication for translators in
the cvsl10n group, proper VCS locking and improvements to the way vcs sandboxes are
managed, and now the last bit involves support for publican statistics (for e.g. release
notes and selinux-guide). 

However, I have no issue with throwing that work away if we can demonstrate that Tx 0.5
will serve the needs of the L10N project better in the given time-frame. My main concern
is the translators and their work flow, and for F11 we owe translators a less crap system
than what we've been using for the last two releases. My secondary concern is
maintainability, and the core of my changes to DL has been ensuring that it doesn't
fail as often, and providing better information when it fails.

Some of the benefits with the new Django-based DL:
- Translation teams can be better organized (Does Tx even have team pages?)
- Translators can indicate that they are working on a specific file
- Options of using a Translator->Reviewer->Committer work flow, I suspect linking up
the actual commit functionality (migrating it from Tx 03 to DL) is less than a day's
work.
- Django based DL has been in production upstream (Gnome L10N) for more than 3 months

So the gist of my message is that we should first look at the how the translation work
flow changes by using these two tools. As I see it, we have four options:

1) Tx 0.5 for stats, Tx 0.5 for commits (not implemented yet)
2) Tx 0.5 for stats, Tx 0.3 for commits
3) DjL for stats, Tx 0.3 for commits
4) DjL for stants, DjL for commits (not implemented yet)

So far I'm a few days away from completing (3), and should also be able to get (4)
done by early next week. If I can be convinced of a clear roadmap for (1) I'd be happy
to help out with that, provided I can see the benefit to the translators with this
approach. However, I am a bit afraid that option (2) might hurt Tx more than it gains in
the long run. Why not focus on getting Tx 0.5 production ready and in shape to become a
great translation platform, rather than simply rushing it in in time for F11? 

Maybe I'm missing something obvious, but *it is* great to finally see a test instance
of Django-based Tx, so don't get me wrong, and I'm guessing a test instance of
both systems will make it easier for us to find the best approach for F11 L10N. I know
there have been plans of merging the Django-based Tx with DL as well, perhaps this might
be a way of developing a migration-path in that direction as well, as I'm worried that
the longer these applications stay separate with active development on both sides, the
harder it's going to be to get e.g. Tx accepted for use in Gnome.

cheers,
asgeir

[1]
https://fedorahosted.org/damned-lies-fedora/browser/stats/management/comm...

Plan for L10n for Fedora 11

[Tóth Zoltán Pálma Camping]

NE ÍRJ!!!!!!!!!

-----Original Message-----
From: fedora-trans-list-bounces(a)redhat.com
[mailto:[e-mail]] On Behalf Of Asgeir
Frimannsson
Sent: Wednesday, February 18, 2009 2:45 AM
To: Fedora Infrastructure
Cc: Fedora Translation Project List
Subject: Re: Plan for L10n for Fedora 11

----- "Dimitris Glezos" <dimitris(a)glezos.com&gt; wrote:
>  I'm very happy to announce that we've now landed support for
>  translation
>  statistics in Transifex.
>  
>  Lately we've been working heavily in re-writing Transifex and getting
>  v0.5 in
>  the best shape possible for Fedora 11. Being 3 weeks ahead of the
>  string
>  freeze, we have plenty of time to test statistics on Transifex
>  0.5-devel.
>  
>  For Fedora 11, my plan is to switch the old DL for Tx 0.5-devel for
>  statistics, and continue to use the proven Tx 0.3 for submissions.
>  I've
>  requested [1] a publictest instance from the Infrastructure Group to
>  install
>  it and start putting data and testing it.
>  
>    [1]: https://fedorahosted.org/fedora-infrastructure/ticket/1191
>  
>  To allow 2 weeks of testing, the instance should be ready by 23/2.
>  When we
>  see that everything works out as it should, we can discontinue the old
>  DL.
>  
>  Our goal with Transifex 0.5 is to include support for both submissions
>  and
>  statistics, and this way we can put aside our old version of Damned
>  Lies which
>  is presenting outdated translations. Since only the commits are
>  missing from
>  Tx 0.5-final, it'll be out in 3-4 weeks, and at that point we go on
>  and test
>  submissions too, while having Tx 0.3 as a backup solution.
>  
>  Some of the advantages of this approach is that using the statistics
>  from Tx
>  0.5-devel does not even require hook-up with FAS (only submissions
>  require
>  authentication), we have a smoother upgrade path for Django/v0.5 and
>  we have a
>  codebase we know inside-out to build/invest on. 
First of all, setting up a test-instance of Transifex 0.5alpha is a good
start, so a big +1 from me. You should probably think of a migration script
for transferring the data as well. I would suggest [1] as a good starting
point for this, as it is based on Django and gets you quickly up and
running.

That said, I have a number of concerns with this approach. Just a few weeks
back you noted that 0.5 wouldn't be ready in time for F11, and that a good
approach would be to migrate to the new Django-based Damned Lies for F11.
Hence, I have spent roughly a week worth of development on this now, and I
am announcing a public test period for this by the end of this week. The
changes we have made to the upstream Gnome version include Fedora-theming
(similar to the existing instance), FAS authentication for translators in
the cvsl10n group, proper VCS locking and improvements to the way vcs
sandboxes are managed, and now the last bit involves support for publican
statistics (for e.g. release notes and selinux-guide). 

However, I have no issue with throwing that work away if we can demonstrate
that Tx 0.5 will serve the needs of the L10N project better in the given
time-frame. My main concern is the translators and their work flow, and for
F11 we owe translators a less crap system than what we've been using for the
last two releases. My secondary concern is maintainability, and the core of
my changes to DL has been ensuring that it doesn't fail as often, and
providing better information when it fails.

Some of the benefits with the new Django-based DL:
- Translation teams can be better organized (Does Tx even have team pages?)
- Translators can indicate that they are working on a specific file
- Options of using a Translator->Reviewer->Committer work flow, I suspect
linking up the actual commit functionality (migrating it from Tx 03 to DL)
is less than a day's work.
- Django based DL has been in production upstream (Gnome L10N) for more than
3 months

So the gist of my message is that we should first look at the how the
translation work flow changes by using these two tools. As I see it, we have
four options:

1) Tx 0.5 for stats, Tx 0.5 for commits (not implemented yet)
2) Tx 0.5 for stats, Tx 0.3 for commits
3) DjL for stats, Tx 0.3 for commits
4) DjL for stants, DjL for commits (not implemented yet)

So far I'm a few days away from completing (3), and should also be able to
get (4) done by early next week. If I can be convinced of a clear roadmap
for (1) I'd be happy to help out with that, provided I can see the benefit
to the translators with this approach. However, I am a bit afraid that
option (2) might hurt Tx more than it gains in the long run. Why not focus
on getting Tx 0.5 production ready and in shape to become a great
translation platform, rather than simply rushing it in in time for F11? 

Maybe I'm missing something obvious, but *it is* great to finally see a test
instance of Django-based Tx, so don't get me wrong, and I'm guessing a test
instance of both systems will make it easier for us to find the best
approach for F11 L10N. I know there have been plans of merging the
Django-based Tx with DL as well, perhaps this might be a way of developing a
migration-path in that direction as well, as I'm worried that the longer
these applications stay separate with active development on both sides, the
harder it's going to be to get e.g. Tx accepted for use in Gnome.

cheers,
asgeir

[1]
https://fedorahosted.org/damned-lies-fedora/browser/stats/management/command
s/migrate.py

--
Fedora-trans-list mailing list
Fedora-trans-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-trans-list

Plan for L10n for Fedora 11

[Sulyok Peti]

2009. 02. 18, szerda keltezéssel 07.21-kor Tóth Zoltán Pálma Camping ezt
írta:
>  NE ÍRJ!!!!!!!!!
>   
Could anyone help this guy to unsubscribe? 
-----> Tóth Zoltán Pálma Camping <palma2(a)enternet.hu&gt;

Plan for L10n for Fedora 11

[Runa Bhattacharjee]

Sulyok Peti wrote:
>  2009. 02. 18, szerda keltezéssel 07.21-kor Tóth Zoltán Pálma Camping
> ezt
>  írta:
> > NE ÍRJ!!!!!!!!!
> >
>  Could anyone help this guy to unsubscribe?  
Ankit has already done it yesterday.

https://www.redhat.com/archives/fedora-trans-list/2009-February/msg00101....

hth

Thanks
Runa

-- 
blog: http://runab.livejournal.com

irc:
mishti or runa_b on Freenode, Gimpnet, Mozilla, LinuxChix