On wiki and translation...
by Bart Couvreur
Hi all,
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
[1]
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?
Possible ways:
* $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
[1] http://fedoraproject.org/wiki/Infrastructure/WikiMigration
--
Bart <couf(a)fedoraproject.org> <couf(a)skynet.be>
key fingerprint: 6AAB 544D 3432 D013 776D 3602 ADB6 6B2A D93F 0F93
16 years, 1 month
Fonts in Fedora
by Ani Peter
Hi All,
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
language.
Grab this opportunity to be the representative of your community and to
speak on behalf of them :-) .
Thanking You
Best regards
Ani
16 years, 1 month
fallout from elvis -> fedorahosted move
by Bill Nottingham
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.
Bill
16 years, 1 month
New module: PackageKit
by Richard Hughes
Multilingual people!
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.
https://translate.fedoraproject.org/submit/module/packagekit
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.
Many thanks!
Richard Hughes.
16 years, 1 month
Localized release announcements and Dictionaries Consolidation
by Dimitris Glezos
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
days).
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
mention it!
http://docs.fedoraproject.org/release-notes/f9preview/en_US/sn-Desktop.ht...
-d
--
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
16 years, 1 month
[Bug 437997] New: "About this Computer" item (about-this-computer) in gnome-system-monitor needs translation
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=437997
Summary: "About this Computer" item (about-this-computer) in
gnome-system-monitor needs translation
Product: Fedora Localization
Version: unspecified
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: l10n-requests
AssignedTo: dimitris(a)glezos.com
ReportedBy: wwoods(a)redhat.com
QAContact: aalam(a)redhat.com
CC: fedora-trans-list(a)redhat.com
(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.
http://cvs.fedoraproject.org/viewcvs/rpms/gnome-system-monitor/devel/abou...
computer.desktop?view=markup
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
months.
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.
16 years, 1 month
Re: pruning the fonts list
by Nicolas Mailhot
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
(probably xorg-x11-fonts-ISO8859-15-100dpi)
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
available
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
space-constrained media
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
cjkunifonts-ukai
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
complain otherwise
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.
Regards,
--
Nicolas Mailhot
16 years, 1 month
Re: Enhancing the fonts list for the KDE live images (was: Re: pruning the fonts list)
by Nicolas Mailhot
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?)
16 years, 1 month
Re: pruning the fonts list
by Nicolas Mailhot
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.
Regards,
--
Nicolas Mailhot
16 years, 1 month