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.
State |
Markup |
not started |
<: #ff8080> please someone take that item |
working on it |
<: #ffcc50> names of the ones working on it |
done |
<: #80ff80> done |
Contents
-
Work items details
- Calendar
- Priorities
- Outreach
- Splitting modules
- glibc locales
- Splitting responsibilities between Coordination Team members
- Define when to consider a module dead
- Discuss dropping DocBook for core modules (extras??)
- Switching completely to words and dropping strings
- Write a mail for to let the translators know about the dinner (DONE)
- Improvements to D-L
- Improvements to gtranslator
- How to consider a translation project dead
- New survey
- Do IRC meetings regularly
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
Status |
Who |
working on a proposal |
Gabor Kelemen |
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
Status |
Who |
working on it |
Gabor Kelemen and PetrKovar |
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:
Status |
Who |
working on it |
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:
- 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...)
Status |
Who |
working on it |
Gabor Kelemen, PetrKovar, AndreKlapper, JohannesSchmid and Leandro |
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
Status |
Who |
not started |
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
Status |
Who |
not started |
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)
Status |
Who |
not started |
Gabor Kelemen and GilForcada |
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)
Status |
Who |
not started |
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
Status |
Who |
not started |
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
Status |
Who |
done |
PetrKovar and GilForcada |
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
- 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)
- icon bigger or the text also being a link (on l10n.gnome.org on a module)
Status |
Who |
working on it |
DanielMustieles, Leandro Regueiro, FranDieguez and AlexandreFranke |
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
Status |
Who |
not started |
DanielMustieles, Leandro Regueiro and FranDieguez |
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
Status |
Who |
Primary contacts:
not started |
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? ...
Status |
Who |
not started |
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...)
Status |
Who |
not started |
No one |