Hi all.
Some members from the L10N project have identified some issues that need to be solved to make sure the translations of Fedora are of high quality. Some of them are infrastructure-related and at today's (-admin) meeting it was suggested to transfer the discussion here.
I'm sure the folks at Red Hat are doing their best to keep the quality of the translations high. But the truth is that Fedora's image in the context of translations is not good; we do hear that a lot, from current and wanna-be members. We can and should work to improve it. Semi-translated applications are U-G-L-Y and shout "low QA" in our ears.
Some possible ideas have been listed on the following page:
http://fedoraproject.org/wiki/L10N/Tasks
Please feel free to chip in and help us out correct whatever doesn't seem reasonable, break tasks into smaller tasks etc.
The bigger picture of some of these problems are:
* L10N of "local" applications (those listed on [1]) is poor; releases and package updates contain untranslated strings in many languages. This is unacceptable for a fully-localized desktop.
* The barrier to contribute to the l10n (be it GUI or Docs) is higher than it should be (compared to other projects).
* QA of the translations is difficult with the current tools.
Some more concrete ideas to discuss that might concern the InfrProj and the RelEng team are:
* Integrate better the handling of translation during a "local" package's lifecycle. Have a flag raised for a package update that introduces new strings so that translators can translate the new strings before the repackaging/updating. Include in the schedule for each release a "string freeze date" and a week later a "translation freeze date" and have all our packages rebuilt after the latter and before the actual release.
* Move po files on their own cvsroot on cvs.fedoraproject.org to reduce complexity and maintenance and to increase security (with a new group).
* Move the i18n status pages to Fedora servers (Plone/Turbogears?). Include a direct link to the pofiles from there so that new members can have something to work on before getting cvs access.
* In the future, use Plone to automate the QA between team members (ie coordinators can review translations etc).
* Start working with the complex and tricky path to upstream translations that no distribution has tackled yet in a successful way. Bring our translators closer to the upstream projects.
Hope some of the above make sense. :)
-d
[1]: http://i18n.redhat.com/cgi-bin/i18n-status
Dimitris Glezos (dimitris@glezos.com) said:
- Integrate better the handling of translation during a "local" package's
lifecycle. Have a flag raised for a package update that introduces new strings so that translators can translate the new strings before the repackaging/updating. Include in the schedule for each release a "string freeze date" and a week later a "translation freeze date" and have all our packages rebuilt after the latter and before the actual release.
String freezes are easy to do, it's just a matter of discipline in sticking to them.
- Move po files on their own cvsroot on cvs.fedoraproject.org to reduce
complexity and maintenance and to increase security (with a new group).
From a maintainer standpoint, the translations *need* to
be in the same SCM system as the code. Without that, you lose features like branching, easy spinning of tarballs, etc. Moving just the po files is not the answer.
- Start working with the complex and tricky path to upstream translations that
no distribution has tackled yet in a successful way. Bring our translators closer to the upstream projects.
Well, the simple answer is if you want to translate upstream, go upstream. For desktop environments, such as GNOME or KDE, this is fairly easy. For other projects, it is more complicated.
Bill
I would like a better way to distribute corrections to translations, after the release date. Many times the translations did not make it in time, for the relaese. This can be both for fedora/red hat programs, but also for other programs like kde, gnome and what-have-you.
I note that, as Linux becomes more and more popular, end users are much less likely to understand English, and the translations are then mandatory for the programs to be usable.
Could this be done as separate packages, or reissues of packages with more complete translations?
and do we need some delta mechanisms for rpm packages to avoid waisting bnetwork bandwidth on small translations updates.
Or is there a need to have several levels of updating, incliding translation updates, security updates, fixes, and facility updates, or should people just always be current?
Do we have the necessary tools to make such things?
best regards keld
On Thu, Nov 30, 2006 at 08:41:37PM -0500, Bill Nottingham wrote:
Dimitris Glezos (dimitris@glezos.com) said:
- Integrate better the handling of translation during a "local" package's
lifecycle. Have a flag raised for a package update that introduces new strings so that translators can translate the new strings before the repackaging/updating. Include in the schedule for each release a "string freeze date" and a week later a "translation freeze date" and have all our packages rebuilt after the latter and before the actual release.
String freezes are easy to do, it's just a matter of discipline in sticking to them.
- Move po files on their own cvsroot on cvs.fedoraproject.org to reduce
complexity and maintenance and to increase security (with a new group).
From a maintainer standpoint, the translations *need* to
be in the same SCM system as the code. Without that, you lose features like branching, easy spinning of tarballs, etc. Moving just the po files is not the answer.
- Start working with the complex and tricky path to upstream translations that
no distribution has tackled yet in a successful way. Bring our translators closer to the upstream projects.
Well, the simple answer is if you want to translate upstream, go upstream. For desktop environments, such as GNOME or KDE, this is fairly easy. For other projects, it is more complicated.
Bill
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-list
Hi,
I do not understand this sentence:
"Do you want to reread or reconsider the Licence Agreement? If not, please shut down the computer and remove this product from your system."
Does that mean that at one point in time I HAVE to reread or reconsider the Licence Agreement? In other words, if I do not read it or considered it AGAIN (once more) I must remove this product?
thnx
O/H Renato Pavičić έγραψε:
I do not understand this sentence:
"Do you want to reread or reconsider the Licence Agreement? If not, please shut down the computer and remove this product from your system."
Does that mean that at one point in time I HAVE to reread or reconsider the Licence Agreement? In other words, if I do not read it or considered it AGAIN (once more) I must remove this product?
The sentence is indeed confusing.
Renato, probably the best thing to do is open a bug report on the `firstboot` component so that the developer looks at it.
-d
Dana Mon, 04 Dec 2006 19:02:58 +0100, Dimitris Glezos dimitris@glezos.com napisali ste:
O/H Renato Pavičić έγραψε:
I do not understand this sentence:
"Do you want to reread or reconsider the Licence Agreement? If not, please shut down the computer and remove this product from your system."
Does that mean that at one point in time I HAVE to reread or reconsider the Licence Agreement? In other words, if I do not read it or considered it AGAIN (once more) I must remove this product?
The sentence is indeed confusing.
Renato, probably the best thing to do is open a bug report on the `firstboot` component so that the developer looks at it.
-d
Thanks Dimitris. It's under: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218340
I've never created a bug report before. Could someone be so kind and check it out? I hope it will be noticed by firtsbook developers, heh.
Thanks again
On 12/4/06, Renato Pavičić repavici@globalnet.hr wrote:
[snipping the content]
Does that mean that at one point in time I HAVE to reread or reconsider the Licence Agreement? In other words, if I do not read it or considered it AGAIN (once more) I must remove this product?
I would assume that it provides you an option to (re)read and/or (re)consider the agreement ie you *may* wish to do so at some point in time, but I read further on that you have opened a bug - so the developer might be best placed to answer it
:Sankarshan
Hi all,
As I reported this to a bugzilla, here is an answer by developer:
----------------------------
Comment #2 From Chris Lumens on 2006-12-04 16:19 EST [reply]
Here's how the UI flows: you get to the License Agreement screen. At this screen, you have a set of radio buttons where you select "I Agree" or "I don't agree". There's also the back and next buttons. If you select "I don't agree" and click next, you get the message in question.
So yes, if you do not agree and want to continue, you are required to reread while on that screen or remove. firstboot won't let you continue until you do something.
Does this clarify things?
-----------------------------
Copied here for others. Thanks Chris for reply.
BR all Renato
Dana Tue, 05 Dec 2006 07:32:07 +0100, Sankarshan Mukhopadhyay sankarshan@randomink.org napisali ste:
On 12/4/06, Renato Pavičić repavici@globalnet.hr wrote:
[snipping the content]
Does that mean that at one point in time I HAVE to reread or reconsider the Licence Agreement? In other words, if I do not read it or considered it AGAIN (once more) I must remove this product?
I would assume that it provides you an option to (re)read and/or (re)consider the agreement ie you *may* wish to do so at some point in time, but I read further on that you have opened a bug - so the developer might be best placed to answer it
:Sankarshan
Since you see value in a delta update mechanism for translation updates. Currently I'm working on a test project "presto" to add such capability. https://hosted.fedoraproject.org/projects/presto/wiki/WikiStart The work is far from complete, but I thought I'd drop a line
On 12/1/06, Keld Jørn Simonsen keld@dkuug.dk wrote:
I would like a better way to distribute corrections to translations, after the release date. Many times the translations did not make it in time, for the relaese. This can be both for fedora/red hat programs, but also for other programs like kde, gnome and what-have-you.
I note that, as Linux becomes more and more popular, end users are much less likely to understand English, and the translations are then mandatory for the programs to be usable.
Could this be done as separate packages, or reissues of packages with more complete translations?
and do we need some delta mechanisms for rpm packages to avoid waisting bnetwork bandwidth on small translations updates.
Or is there a need to have several levels of updating, incliding translation updates, security updates, fixes, and facility updates, or should people just always be current?
Do we have the necessary tools to make such things?
best regards keld
On Thu, Nov 30, 2006 at 08:41:37PM -0500, Bill Nottingham wrote:
Dimitris Glezos (dimitris@glezos.com) said:
- Integrate better the handling of translation during a "local"
package's
lifecycle. Have a flag raised for a package update that introduces new
strings
so that translators can translate the new strings before the repackaging/updating. Include in the schedule for each release a
"string freeze
date" and a week later a "translation freeze date" and have all our
packages
rebuilt after the latter and before the actual release.
String freezes are easy to do, it's just a matter of discipline in sticking to them.
- Move po files on their own cvsroot on cvs.fedoraproject.org to
reduce
complexity and maintenance and to increase security (with a new
group).
From a maintainer standpoint, the translations *need* to
be in the same SCM system as the code. Without that, you lose features like branching, easy spinning of tarballs, etc. Moving just the po files is not the answer.
- Start working with the complex and tricky path to upstream
translations that
no distribution has tackled yet in a successful way. Bring our
translators
closer to the upstream projects.
Well, the simple answer is if you want to translate upstream, go upstream. For desktop environments, such as GNOME or KDE, this is fairly easy. For other projects, it is more complicated.
Bill
-- Fedora-trans-list mailing list Fedora-trans-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-list
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Hi all,
There are lines like:
</_description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq type="optional">compat-db</packagereq> <packagereq type="default">compat-libgcc-295</packagereq> <packagereq type="default">compat-libgcc-296</packagereq> <packagereq type="default">compat-libstdc++-295</packagereq> <packagereq type="default">compat-libstdc++-296</packagereq> <packagereq type="default">compat-libstdc++-33</packagereq> <packagereq type="optional">compat-slang</packagereq> <packagereq type="optional">compat-readline43</packagereq> <packagereq type="optional">compat-openldap</packagereq> <packagereq type="optional">openmotif22</packagereq> <packagereq type="optional">openssl097a</packagereq> <packagereq type="optional">qt4</packagereq> </packagelist> </group> <group> <id>mail-server</id> <_name>Mail Server</_name> <_description>These packages allow you to configure an IMAP or SMTP mail server.
Jeez!
Where's the text to translate here? And in the othe lines as well? Is there no other way to approach this?
thnx
-
Ahmed Kamal -
Bill Nottingham -
Dimitris Glezos -
Keld Jørn Simonsen -
Renato Pavičić -
Sankarshan (সঙ্কর্ষণ)