The today Go/No-Go meeting is a No-Go for RC1, the GA has slipped to
That is going to let you more time for translations, which is not too
We've just managed to have the fedoraproject.org website ready for
The content is not fully written yet, but which is aleady written should
We just miss a small Clouds section, and changes in the interviews
But what you are actually able to translate is all that we can give you
The TXN fedoraproject.org f17-beta release has been locked, and merged
in the unlocked master one, at
Proofreading is made at http://stg.fedoraproject.org/
The spins.fpo is going to be updated ASAP, be aware that some strings
will change shortly.
Please, report to us any typo.
Thanks, happy translating!
- Name: DaGo
- Location: Grenoble, France
- Login: dago
- Language: French/English bilingual
- Profession: Software Engineer
- About You:
Hi, I am a French national who has lived in the US for several years.
Being part of the Fedora translation team seems to me like a great way
to learn about Linux and give back to the community at the same time.
- You and the Fedora Project:
I have a fresh install of Fedora 16 on a VirtualBox. Let the fun begin!
- pub 2048R/D4D61E14 2012-04-15
Key fingerprint = 6449 DDF0 9833 497E C3D9 9097 8B02 B47A D4D6
sub 2048R/BC6A486A 2012-04-15
At the last Board Meeting, the Board looked at the poll results asking
whether people felt like continuing to name releases. The results seemed
to show that many people do like having a name associated with Fedora
releases. However, the discussion before and after has shown there is
a desire to improve upon the current method of selecting the names.
The Board decided that it would be worthwhile to come up with a new
procedure for selecting the name for the Fedora 19 release and beyond to
attempt to solve some of the issues that have been brought up. The Board
is looking for volunteers who would like to do two things:
(1) Answer the following questions:
* What benefits does the Project get from the current release naming
* What changes do people want to see in a revised process?
(2) Come up with at least one proposal and analyze it according to the
answers to the previous questions.
If anyone is interested in coming to a weekly meeting to work on this,
please feel free to contact me. If anyone would like to champion this,
please contact me ASAP so I know whether there is someone else who's going
to champion this or if I need to lead the effort.
I've put up a wiki page that tries to summarize the answers to the first two
questions that I've seen circulated on the advisory-board mailing list and a
link to the only proposal I currently know of (mizmo's proposal to use
a single theme for all of the new Fedora releases).
Name: Jiro Matsuzawa
About me: I am a member of the GNOME Foundation. I translate GNOME
Me and the Fedora Project: I am a Fedora user. I hope to contribute to Fedora.
GPG Key ID: ECC442E9
GPG Key Fingerprint: E086 C14A 869F BB0E 3541 19EB E370 B08B ECC4 42E9
Check out the RPM and the translations and give karma. This corrects
all the outstanding bugs.
There are a few new untranslated strings.
- I added a revision history entry for 17.0 but Publican seems to
think this is already translated.
- I added the Bulgarian and Ukranian translators names to the
contributors - these shouldn't need to be translated.
I will continue to build new RPMs as new translations become available.
We had a rash of bugs to the release notes, many from translators --
thank you very much. We appreciate that.
However, that did result in having to push updated POTs. Most are tiny
typo changes, but in one case there is an entirely new section,
My apologies for the late change, especially to the Ukranian team who
was complete. Most of those I should have caught earlier, although
there is no way I would have caught the installation change.
Thought of forwarding it here as it also occurs with us in most of the
Fedora packages where Fedora is upstream. We (translators) always try to
find out where did we miss the translations when we find that a
particular package has something viewed in English during the testing phase.
So, developers, please please check or make sure that you are marking
all translatable messages as translatable, otherwise it would never come
to us (translators) and would never go to end users as localized messages.
Thanks a lot!
-------- Original Message --------
Subject: Please check your sources for strings not marked for
translation before release
Date: Mon, 07 May 2012 13:59:45 +0200
From: Kenneth Nielsen <k.nielsen81(a)gmail.com>
To: gnome-i18n(a)gnome.org, desktop-devel-list(a)gnome.org
Since the release of GNOME 3.4 we have received a steady stream of
emails saying "This is not a string freeze break, we just forgot to mark
the strings for translation". So much so, that the statistics e.g. for
my language (which has not been touched since release) now counts 63*
untranslated or fuzzy strings in a source that was at 0 at release time,
three weeks ago.
I understand the reason for not counting marking existing strings as a
string freeze break. But please understand that even though you are in
your right to fix things like this post release, and even though it off
course makes sense to do it, it does not mean that it is not annoying
and a burden for translators.
The reason for this is that we concentrate large amounts of work in the
period just before release (where string changes are relatively quiet),
so therefore it is also an advantage for us if we can finish as much of
it as possible in that period (of course also because a lot of us has an
extra hat as distribution translators for distributions that follow
within a month or so of the gnome release). On top of that, small
updates are uncharacteristically expensive in a work/string-sense
because they involve the same amount of emails back and forth for
proofreading and git work.
So please... If you could make a bit more of an effort of checking your
sources for non-internationalized strings before release that would be
great. IMHO 63 is just a bit on the high side of where this number should be
* These 63 off course also include genuinely new strings due e.g. to bug
gnome-i18n mailing list