The goal of the GTP BoF at GUADEC 2012 is to present current issues about the GNOME Translation Project.

This event is an opportunity to meet up and discuss common issues and best practices in GNOME localization.

The below minutes describe what was discussed and who was interested in. Please use the gnome-i18n mailing list to coordinate efforts.

Work items details

Calendar

Background:

There are lots of modules that are not released on a 6 months basis as our beloved GNOME Desktop. In that sense, having a way to show or list modules about to be released will help translators spend their time on modules that are about to be released, and thus making shorter the time a translation is done and the software is released.

Bullet points:

• how to make the developers notice us about new releases
• proposal design, visuals about how could be shown on l10n.gnome.org

Priorities

Background:

The previous point raises the importance of deciding where to spend translation resources, which module is more important... Which brings to a discussion about how to rate the modules, how to sort, etc.

Bullet points:

• brainstorming about ways to prioritize:
  • automatically move to the bottom the "dead" modules (look at the working item about it)
  • show the last commit not being a translation so translators can sort on that
  • allow translators/coordinators to "+1"/(or "up"/"down") so that the sorting is decided by translators
  • show the amount of translations already for that module and be able to sort on that
  • try to convince developers about creating stable branches when about to make a new release

Outreach

Background:

GNOME Translation Project is known for its quality and amount of translations, but quite a few translation teams said on the survey that more (wo)man power would be good. Thus, trying to make coordinated actions about outreach that can be reused and remixed from local teams when doing outreach would help everyone of us. Also contacting coordinating translation teams from other projects (KDE, Sugar, LibreOffice, Firefox ...) could lead to lots of interesting ideas.

Bullet points:

• More detailed overview.

Splitting modules

Background:

GNOME is massive there's no way that even the more dedicated translation teams will be able to reach the desired 80% starting from scratch within a release (6 months) and not even with two releases (12 months). So splitting the release set to smaller sets would help reduce the amount of work to be done while not removing any important module not translated.

Bullet points:

• Work in progress page

• decide the new 80%
• think about changing the reduced ui po files to only strings coming from .ui files (glade files) and strings with mnemonics (menus, interface elements ...)
• badges about what a language supports (like a11y if a a11y set is made...)

glibc locales

Background:

Now and then new translation projects appear on GNOME i18n mailing list. Sadly most of them needs to create a glibc locale, which is both a tedious and a complex process in itself. Having some expertise and knowledge about how the glibc locale does work, knowing who can help on both creating the locale and getting the locale on glibc will greatly help those new languages.

Bullet points:

• we need to gather some expertise on it

Splitting responsibilities between Coordination Team members

Background:

Currently the Coordination Team is not completely defined in itself, which tasks, which responsibilities, which powers and duties has, etc.

Compiling a list of all this and making all Coordinator Team members decide where they want to work on would help knowing the team's strength and limitations have.

Bullet points:

• document which are the responsibilities and who takes care of them
• expand the team? make all the translators aware of the responsibilities and if they are fine with it
• ask for renewals of members, to know the current available members

Define when to consider a module dead

Background:

Translating a module and knowing afterwards that even if the translation is pushed there will be no more releases because the developers of it just left, is unmaintained, etc is sad and really frustrating for translators. Helping identifying which modules are dead and showing that to translators will help reducing this kind of frustration and making translators spend its time on modules which eventually will see releases.

Bullet points:

• right now: 2 years without commits (asking the maintainer before)
• look out strategies to see which modules are not worth translating right now and contacting as soon as possible the maintainers about its status and further development/releases
• some sort of git-fu scripting, showing/marking that on Damned-Lies so that translators clearly see where to spend their time
• sending automatic emails every 6 months to maintainers if a module has translations committed but no release has been made (a git tag)

Discuss dropping DocBook for core modules (extras??)

Background:

The Documentation Project is switching all documentation to Mallard format, thus all DocBook documentation still around will be rewritten in Mallard. For translators that means that not only the source format of the documentation will be changed (still translators will use regular po files to translate them) but also that the previous strings will not be that much useful if at all.

Still, the Documentation Team should be the first and last one to decide if a documentation is worth translating or not.

Bullet points:

• Contact the documentation team and having some sort of priority (see the above points about prioritizing)
• Try to see if they like the idea of sorting/prioritizing the modules on D-L interface (or some other easy way to do so)

Switching completely to words and dropping strings

Background:

For a strings

Bullet points:

• Asking the sysadmin team about a preview instance where we can try things and let everyone see it and decide upon informed knowledge about the matter
• set a preference per-user (I want to see words/strings)
• use words for all statistics but a combination of words and strings statistics for the 80%
• we have to work out something that most agree on

Write a mail for to let the translators know about the dinner (DONE)

Background:

The Board of Directors, during GUADEC, decided to give a special thanks to all members of the translation team that were able to be there. After the dinner, the translation team members decided to write a mail extending the gratitude expressed by the Board of Directors to all members of the GNOME Translation Project.

Bullet points:

• write the mail and send it

Improvements to D-L

Background:

A brainstorming session was run over which improvements will be nice to have on Damned-Lies. Right now D-L is short on developers, so having a bullet point in this list does not mean it will be implemented in short or at all if the situation does not change.

Bullet points:

• QA tools on D-L
• integrate posieve (write a set of rules of warn about and so)
• tmx export (translation memory)
• tbx export (terminology memory)
• create a po file made out of a tbx export (update for every release?) so that translators can have already a consistent terminology
• documenting the tools on l.g.o
• look at pylyglot for inspiration?
• pretranslate strings (marked as fuzzy) so that instead of downloading .pot files you already

• ping the design/web team about the vinicius design

• talk with the sysadmin team for the git thingie
• transifex?
• RSS with modules with untranslated strings
• checking documentation syntax to not break things
• reach documentation team about how to generate the xml files to see (both docbook and mallard) so that we can see it locally on yelp
• Send reminder about pending translations to be pushed (some stats and links)

• https://bugzilla.gnome.org/show_bug.cgi?id=667207

• icon bigger or the text also being a link (on l10n.gnome.org on a module)

Improvements to gtranslator

Background:

A brainstorming session was run over which improvements will be nice to have on gtranslator. Right now gtranslator is short on developers, so having a bullet point in this list does not mean it will be implemented in short or at all if the situation does not change.

Bullet points:

• open to review patches

How to consider a translation project dead

Background:

Just like knowing if a module is dead will allow us to tell translators not to translate that module, knowing if a translation project is dead will help us trying to reach the translation coordinator for that language to know the status of the project, if they need help, if they need someone to step in as a coordinator, etc.

Bullet points:

• Do like with modules? Every release send a mail to them if they haven't done any commit during that period.

• AndreKlapper template to contact language coordinators

Primary contacts:

New survey

Background:

As there was a lot of things to discuss on the BoF, maybe it would make sense to ask the coordinators to give their opinion about them.

Bullet points:

• which kind of questions should be added
• send the survey to Coordinators? to everyone?
• which format to use? email as the first one? on-line? ...

Do IRC meetings regularly

Background:

To keep the team updated, bring in new ideas, review the status of the current ones, etc

Bullet points:

• decide the periodicity
• make sure that before and after the meetings there is some buzz about it (blogging on p.g.o, mail on the gnome-i18n mailing list...)