you might have heard about the up and coming wiki migration from our
current moin-instance to the likely better working mediawiki. This as a
result of all sorts of problems with moin. For more info, see the wiki
As a result of this, we've got the chance to rethink how we organize our
translations of the wiki. Do we want to keep the current structure, or
do we want to formalize it and create some guidelines for wiki
translation, to be used in the new setup?
* $lang-code/$English_title: keep the same structure of the
English original wiki, just insert a lang code (somewhat like
how the main website is set up)
* $lang-code/$translated_title: translate the structure
* $English_title/$lang-code: create sub-pages of a certain page
with the translation
Looking at how Wikipedia has set up their mediawiki, it should be
possible to create a list of translations of a certain page.
So any ideas, suggestions, questions, ... anything, shoot :-)
Bart <couf(a)fedoraproject.org> <couf(a)skynet.be>
key fingerprint: 6AAB 544D 3432 D013 776D 3602 ADB6 6B2A D93F 0F93
Have a look on this page: http://fedoraproject.org/wiki/SIGs/Fonts
I think we LMs should be filling up this page. This would help us to
know which font is the most used and demanded by our community and why
do they prefer to have that included in Fedora. Also, this could provide
us the feedbacks from community on the problems with existing fonts and
how to develop them. All these, in turn will help for the betterment of
Fedora and have future releases with community preferred font for our
Grab this opportunity to be the representative of your community and to
speak on behalf of them :-) .
Was there supposed to be a step where the old repositories were
removed from elvis?
We ran into a case today where for one module (system-config-keyboard)
the only thing that was done is that at some point the translations
were 'cvs rm'd, leaving all the code there (which, by the way, is
a horribly broken way to try to disable the repo). Development was still
going on in the elvis repository, and now we have divergent trees.
Dimitris Glezos has setup the PackageKit project to use Transifex. This
means translations can be synced with our private git server, and all
the authentication dialogs and daemon client tools can now be localised.
The gnome-packagekit is still translated by the GNOME intlteam, but the
daemon has some strings that are security sensitive, and are essential
to be translated.
If you have any questions about the strings, please don't hesitate to
ask. Please just commit translations freely.
As usual, we encourage local teams to create their own announcements
for the new release, in a tone and context that fits more the local
community and touches users in a more intimate way. We're getting
together some highlights that you might want to include and base your
announcement on, which should be out sometime before the release (4-7
An important feature for localized desktops that isn't included in the
official announcement and highlights is The Dictionaries
Consolidation. This is a killer feature of F9 for localized desktops,
so those of you who'll create their own announcement make sure you
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: "About this Computer" item (about-this-computer) in
gnome-system-monitor needs translation
Product: Fedora Localization
(Apologies in advance if this isn't the right place for this..)
The "About this Computer" item was added to the System menu in Rawhide on March 8. It's provided by
about-this-desktop.desktop, in the gnome-system-monitor package.
This is a Fedora-specific feature right now - it''ll be moved upstream sometime after F9. But I don't
want to add a whole transifex module just for one string that will be moved upstream in the next six
How should I go about getting it translated for F9?
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Le vendredi 18 avril 2008 à 15:57 -0400, Bill Nottingham a écrit :
> When looking over the LiveCD manifest, and where space is going, I
> can't help but notice that a lot of it goes to fonts. Here's the
> full list, AFAICT. The number to the left is the size of the package.
> I think a good chunk of this could be pruned.
My advice would be:
1. drop every core fonts package except one to keep legacy users happy
2. drop xorg-x11-fonts-Type1. Nothing in there not provided by more
modern font packages
3. fonts-japanese is probably not 100% necessary when VLGothic is
4. drop culmus — DejaVu full includes Hebrew no one complained of during
the F9 cycle, so no need to keep a separate Hebrew font on a
5. Have the Arabic l10n group choose between kacst and paktype
6. Have the Indic l10n group sort the huge number of indic fonts,
keeping only one package per script (sarai, lohit, smc, samyak)
7. Have the Chinese l10n group choose between cjkunifonts-uming and
8. add dejavu-fonts-experimental — you *really* want the distro default
fonts to have a complete face set, a lot of users will notice and
I'm afraid most wins are in 3. 5. 6. & 7., and they depend on l10n
groups telling us their wishes, which unfortunately has not happened a
lot so far. http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/L10N
remains terribly incomplete.
Le samedi 19 avril 2008 à 00:36 +0200, Sebastian Vahl a écrit :
> I've got a similar question here for the KDE live images. At the moment
> our fonts list is:
At first glance you could use pretty much the same advice as the live
spin, except you've already followed some of it, and you have support
for some scripts the main live spin is missing (which is good, if you
have the space). For example : tibetan & ethiopic (abyssinica).
If you really wanted to save space, you could drop the urw & ghoscript
fonts, but I suspect you may have some packages depending on them
explicitely. They don't add coverage, and they're not really good screen
font, but they do provide some standard font metrics (is it worth some
live cd space?)
Le samedi 19 avril 2008 à 02:59 +0530, Rahul Sundaram a écrit :
> Nicolas Mailhot wrote:
> > 6. Have the Indic l10n group sort the huge number of indic fonts,
> > keeping only one package per script (sarai, lohit, smc, samyak)
> Lohit is what we prefer by default for Indic. Everything else can be
> deemed optional.
Since they're all broken up by scripts now you probably want to be more
specific, unless lohit provides every needed indic script and none of
the others is necessary for coverage.