## Description of problem:
Many of the strings of test & final releases do not reflect the translations
that were made until their devel freeze date.
## Actual results:
Applications contain half translations.
For example, the greek translations of more than 5 major packages (anaconda,
firstboot, -config-date, comps-po etc) of FC6T3 are outdated, even though the
changes were made 3 days before the freeze date.
## Expected results:
All releases should contain all translations that were made up to the
development freeze date. Packages should always be rebuilt to contain the most
## Additional info:
The current trend is for maitainers to package only if it is needed. If a
translator commits some important changes, he should notify the maintainer and
ask him to rebuild his package.
Since we have many languages and between releases there are changes to most of
the Core packages for each of this language, the possibility that a package
needs rebuilding is nearly 100%.
Test releases are the only way to check packages like anaconda and firstboot and
are an important way of receiving comments/bugs from the community and
corrections from the fellow translators. Translators work hard to have good
translation coverage in every test release and the actual ISO should contain all
See also: #204895
As already explained in the Fedora-trans-list mailing list, this is a rather
important issue and affects everyone involved in translations.
The same is happening with Brazilian Portuguese Translations. In my opinion, at
least the essential packages and the system-config-* ones should include newer
translations. For instance, system-config-printer is a 100% translated, but the
module shows a English-Portuguese mix on FC6T3 and it is a very important module
The individual packages need bugs filed against them when translation updates
are ready to be built in. Feel free to use this as a tracker bug for these bugs.
we understand that this is the procedure followed now. AS Alam explained it and
I included it in the bug report.
What we are asking, and it seems many translation teams want this, is to alter
the way repackaging of system-config-* currently works and *always* repackage
before releases without the need of opening a bug against them.
Probably should be handled by the individual maintainers of those packages, not
as a rel-eng item. system-config* packages aren't the only ones that get
translations either. The translation team really should be working with the
package maintainer to let them know when new translations are ready to be picked
up, especially once freeze dates near.
> The translation team really should be working with the
> package maintainer to let them know when new translations are
> ready to be picked up, especially once freeze dates near.
What I am trying to say is that translatios are always ready to be picked up
(and should be) before releases.
I'm sure there is a better way to have this done except opening bug reports to
the 50 packages that are maintained through i18n.redhat.com every time a release
I'll give a suggestion that just came to my mind. We could create a page on the
wiki with the following structure:
Package | Rebuilt for FC6? | Date of rebuild
-------- | ---------------- | ------------------
anaconda | yes (JeremyKatz) | 16/7/2008
and the translation team (with the blessings of the rel-eng team) could make
sure all maintainrs of these important packages had them rebuild. If we have a
date on the Core schedule that this table should have "yes" in all rows, then I
think the translation team could send an email to the maintainrs one week before
the deadline reminding them for the repackaging job.
This new measure is something that I believe should have the approval and
blessings of the rel-eng team. It is something that will definitely increase the
quality of the final product in the non-english languages.
Possibly workable. The date would be maybe one or two weeks after the
translation deadline. This would give the packagers a chance to pull in the
translations, but also give the translation team a clear point of no return, a
hard "you must be done by this date" thing. I think a bug isn't the best way to
continue this discussion though.
Closing this as bugzilla is not the place to have this discussion.