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
We have updated the design and contents of our home page *http://zanata.org/
<http://zanata.org/>* for better user experience.
Any feedback is welcome.
SENIOR SOFTWARE ENGINEER, team lead
globalisation tooling, customer platform
Red Hat Asia-Pacific Pty Ltd <https://www.redhat.com/>
aeng(a)redhat.com M: +61423353457 IM: aeng
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.
We are going to have a short meeting on #fedora-g11n in 15min. Agenda is
only T-shirt for contributors who contributed over 500 words in 2016. 
We are almost in last stage of it, if anyone available feel free to jump
Apologies for short notice,
During Friday's FESCo meeting we were asked to approve a change to
the release schedule to accommodate translation string freeze deadlines
that somehow got left out of the new "no-alphas" schedule.
Several participants pointed out that Fedora has not enforced the
"string freeze" in many years, despite it being on the schedule until
now. Thus, we would like to revisit the string freeze policy to
determine if it is still valuable, and if so, how can/should it be enforced?
We'd like to explore a couple of questions:
* What exact things are frozen? Things like comps make sense to follow
Fedora freezes, but do things like anaconda? or system-config-printer?
* Can we automate some way of enforcing or at least detecting when
something changes a string in the freeze?
This ticket tracks the issue:
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).
I need some help with Fedora documentation. I have uploaded on GitHub
the german .po-files for the Flatpak documentation sitting here:
First of all: Is there interest in this one? If yes:
What is it that I have to do now in this special case? There is need
for a review of course. I could imagine some revisions eventually, but
it is something you can work with ... ^^
Somebody who is willing to do a review on this? Or maybe give me an
helping hand to find the needed information to optimize the
translation? And do all this here the Fedora-way? I have read the l10n-
guide, but i am lost now a little bit.
I apologize for the missing introduction of my person, but I have lost
my poetry album for today. I will write some words in the following
during discussion on the FLOCK it has been realized we have some issue
with Software String Freeze milestone. The issue is caused mostly by
changing some key milestones as a consequence of "No More Alphas"
In the past the Software String Freeze milestone was tight together
with Alpha Freeze. After we implemented the "No More Alphas" Change
 and we moved Branching closer to Beta Freeze, we are now in the
situation when we need to come up with some conclusion how to plan the
Software String Freeze milestone. AFAIK there are two requirements
this milestone should fulfil:
* The milestone needs to be planned after Branching
* There should be enough time for translators to do the job before
Software Translation Deadline (which is currently planned two weeks
before Beta Freeze)
Having the Branching 3 weeks before Beta Freeze does not give enough
room for translations (comparing to the state before implementation of
"No More Alphas" Change ). What I see as a possibility now is to
have the Software String Freeze milestone one week after Branching and
move Software Translation Deadline to the same date as Beta Freeze.
This gives us the maximum time period between the "Software String
Freeze" and "Translation deadline" we can currently have (even it is
just two weeks).
What do you think ? Will such a timing works for these two milestones
( Software String Freeze & Software Translation Deadline ) ? Or anyone
have a better proposal ?
Thanks for any feedback,
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic