Re: GUADEC's GTP BoF summary



On Wed, Aug 1, 2012 at 7:00 AM, Gil Forcada <gforcada gnome org> wrote:
> Wow, that's quite a lot of acronyms :)
>
> Anyway on topic...
>
> As some of you have already seen we (all translators and GTP Coordinator
> members) that were at this year's GUADEC meet on 30th of July all day
> long to discuss about the 14 topics listed on the wiki page about the
> meeting:
> https://live.gnome.org/TranslationProject/Events/GTPBoFGUADEC2012

Thanks for the summary of the discussion for those of us who could not
attend GUADEC.

> Please bear with us, as the notes maybe do not make much sense for
> someone not on the BoF. We all (BoF attendees) will try to clean them up
> and maybe it would make sense to send a mail (even if that will be 14
> mails) on this mailing list explaining the idea of each of them.
>
> This way we can add every one of you on the loop of the current
> activities and motivations behind all this 14 points.

There does not appear to be a Discussion page on the wiki, so I am
hoping that comments on this list about individual elements of the 14
follow-up actions points will be welcomed.  Otherwise, please specify
an alternate feedback mechanism.

Item: Making guidelines

As Gil previously mentioned, it is indeed great to see new languages
coming to Gnome.
https://mail.gnome.org/archives/gnome-i18n/2012-July/msg00118.html

I went looking the documentation on the wiki that offered general
advice to new language teams on how to prioritize their work on Gnome
and the best guidance I've found is this:

https://live.gnome.org/TranslationProject/LocalisationGuide?highlight=%28CategoryGnomeI18n%29#Choosing_the_first_packages_to_translate

I think some more extensive guidance on prioritization would be very helpful.

Consider the daunting scope facing a team first looking at Gnome L10n:

41K   3.6 release set
 3.3K External Dependencies (GNOME) release set
11K   GNOME-Office Productivity Applications
 4.2K GNOME Infrastructure
10K   GIMP and Friends
10K   Extra GNOME Applications (stable)

~80K total

At the risk of sounding self-serving, one might consider suggesting
the OLPC Release set as a starting point.

~30K  OLPC Release set (drawn from across the above Release Sets on
the basis of providing a minimalist, but fully functional Gnome boot
on OLPC OS images.)  Admittedly this is not perfect.  Some clearly
lower priority items are included.

 4.2K from GIMP and Friends
 6.8K from libg-weather
 5.8K from gnumeric

which do not necessarily merit prioritization in the overall scheme of
things.  Skipping these would give an OLPC designated set in the 13.2
K range covering a lot of highly user-visible packages.


Item: Just reaching out to local communities

I personally think the concerns about perceived "poaching" of
localizers is overblown and even a little insulting to localizers.
Localizers are free agents and work on what they choose, when they
choose.  In my experience, localizers are (for the most part)
characterized by language loyalty more than package/distro loyalty.

Another option which carries no "poaching" stigma is to promote Ui
string harmonization across orthologous packages (packages performing
the same or similar functions in different distros).  For example, why
do Gnuchess, glchess from gnome-games and Knights from KDE have so few
strings in common?  Surely the basic text to describe a chess game
could be harmonized to a greater extent and shared across these
packages whose primary differentiation has to do with back-end chess
engine support.  Newspaper chess columns (for those of you who still
look at print media), has standardized on a short and frankly ugly
alphanumeric terminology for describing chess moves and entire games
in a compact fashion.  Surely, we can do nearly as well.

There are also clear opportunities in word processors and other
commonly implemented packages (networking apps, etc.).  How many
different strings does the FOSS world really need to describe
indentation and other common typesetting functions?

English searches in open-tran.eu will identify plenty of chances to
reduce string variability (and increase consistency) across projects,
some of which might even be appealing to developers if offered in the
context of more rapid or broader L10n coverage.

Item: glibc locales.
I definitely have some strong opinions in this area, but I'll table
them for now as this message has rambled on long enough.

These are just a few thoughts of my own on some the agenda topics raised.

Warmest Regards,

cjl
Sugar Labs Translation Team Coordinator


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]