I am sure, most of the people working with Fedora I18N, L10N from 5-6
year must be aware regarding Fedora L10N Steering Committee.  As far
as i know this committee was active around 2009 and very effective.
During Fedora G11N activity day discussions, we again felt there is
need for some kind of official committee to drive Fedora Globalization
activities. Fedora is growing faster with number of different domains
and G11N also need to adapt those changes quickly to remain on the track.
For this purpose and in line with , we were thinking of Fedora
Globalization steering committee. I have created initial proposal for
Its open for feedback, please feel free to share other active members,
discuss in your respective language groups. This is just initial
proposal and i am sure, we can improve and make it more effective with
g11n mailing list
Bug ID: 1361757
Summary: Typo in the czech localization Anaconda installer
Product: Fedora Localization
Component: Other language
QA Contact: aalam(a)redhat.com
CC: dimitris(a)glezos.com, piotrdrag(a)gmail.com,
Description of problem:
Typo in the czech localization Anaconda installer
Version-Release number of selected component (if applicable):
Fedora 24 x86_64
Downloaded workstation version from website https://getfedora.org/
Start czech installer any time and go to disk management.
Select manual partitioning.
You should be now on this screen:
You are receiving this mail because:
You are on the CC list for the bug.
My name is Takuro Nagamoto. I am a Japanese translator at Red Hat, based in Brisbane, Australia.
I just wanted to let you know that I took over a coordinator role for Fedora Japanese translation from Noriko, who left Red Hat in January (greatly missed).
Hope to contribute to the Fedora Japanese translation team as a coordinator/translator/reviewer (I already have those privileges granted on zanata).
just a short introduction.
Name: Thomas Eichhorn
About me: I'm using Linux since 8 years now and Fedora since Fedora 13 or 14. Because this project is so great and runs my personal laptop, I
want to give the project something back and contribute to the German translation.
I've already contributed to one OSS project as an translator: Xibo (http://xibo.org.uk/)
GPG KEYID and fingerprint:
pub rsa2048 2017-03-26 [SC]
4FF6 3341 F219 BB5F 1DD0 49A9 4CAF 37B5 8E21 F952
uid [ ultimativ ] Thomas Eichhorn <tomislav(a)posteo.de>
sub rsa2048 2017-03-26 [E]
Fedora 27, due out October 2017, will not have an Alpha release. We're
adjusting the schedule around that, and there are some questions as to
where the put the translations deadlines. Traditionally, String Freeze
is defined as "Same day as Alpha Freeze", so obviously that's no longer
Take a look at the schedule as it stands now:
Right now, we the string freeze about a month before the beta freeze
(basically, in the same timeframe). This, however, includes putting the
string freeze before Bodhi Activation (which also used to happen at
Alpha) and even before the branch from Rawhide. This seems less than
On the other hand, the Translation Deadline is usually a bit before the
Beta freeze. If we keep that _and_ move the String Freeze up to the
branch, that leaves only a week to do translations. If we move the
String Freeze up to the Bodhi Activation point, that puts it *after*
the Translation Deadline, which obviously makes no sense.
In this new model, were *should* these deadlines fit? Is it reasonable
to put the Software String Freeze the day of the branch (2017-08-16)
and the Translation Deadline at the Beta Freeze (2017-09-05), or is
that too late? What about putting the Software String Freeze at branch,
and Translation Deadline just two weeks later at Bodhi Activation
Fedora Project Leader
Just discovered that I cannot disable a format check on Zanata,
which claims that number of apostrophes in translated message is
not the same as in original message. It is for sure ok,
since we don't use apostrophes in Kazakh language.
How do I force Zanata to accept this translation as valid?
The only option is to save it as fuzzy translation.