Re: minutes from GUADEC2 translation BOF

Hi all,
	See below for a couple of comments

Keld Jørn Simonsen wrote:
> Here are the minutes from the Gnome translations  BOF at GUADEC 2.
> We held 3 BOF sessions Friday/Saturday/Sunday 2001-04-06/08
> at Symbion in København.
> I may have remembered things wrongly, or ommitted something.
> Please send corrections and additions to the list, I will then
> issue updated minutes. I think it would be useful to put these
> minutes up on the web pages, and then track what is happening
> with the issues.
> The idea with the BOF was to discuss issues and possibly get
> closer to a solution.  I had prepared some issues for discussion,
> others also put up some issues.
> We were about 8 to 14 people in the BOF.
> 1. Quality assurance
> We discussed issues beyond getting 100 % translated
> - has the .po file been spellchecked?
> - has it been reviewed by other persons?
> - has it been run in practice?
> We agreed that the following was a good idea, and recommend
> it for inclusion in the gettext tools:
> In the .po file for each message, list
> - when spellchecked
> - when and whom reviewed
> - each line verified in run, when and by whom
> Implement it as .po comment lines:
> #, spellchecked 2001-04-05
> #, reviewed 2001-04-06
> #, verified date email
> The gettext tools should then remove these lines when
> the mesgid is changed.
> We would like a windows manager for verifying the executed apps.
> Running the program and clicking a text or a whole
> page should automatically mark it as ok or wrong in the .po file.
> We thought that it would be next to impossible to have people
> do this by hand, so we need assistance from a general
> windows manager.
> 2. Error reporting
> There are two kinds of error reports, one is on the original
> msgid's, the other is on the translated msgstr's.
> If the bug is something that  relates to the operation of the
> program the message in error should be brought back to the
> developers team. This is a problem, as the message in
> question is in many cases displayed translated.
> It should be possible to write an error report in the translated
> language, which then would not be understood by the developers, so
> it should be sent to the translators error-list, who then
> after translation could forward it to the developers.
> If the error is one in translation, then the message should
> be sent to the translator, or the translator team.
> The email addres to report translation errors should be listed
> in the "about" box for all programs, and integrated in the
> bug reporting system, bug-buddy. There could then be a
> list for each language centrally located for all gnome
> packages, and with some ticketing system integrated.
> For the same language there could be different error-addresses
> for different packages.
> It was proposed to give every message a message number.
> I dont think we agreed on that.
> 3. Use of translation memory
> maybe do it automatically on CVS derived files?
> KDE has a base of text that is translated, such as
> "yes, no, cancel". We could centrally build total
> .po files of messages. Some of the sofware here is
> real s-l-o-w tho.

I think use of a translation memory would help reduce translator's work
(removing "stock terms" from their workload) as well as helping to
increase the consistency. However there is a lot of work in implementing
a translation memory that is both useful and accurate. Ensuring a high
quality of translations in the translation memory is also a lot of work
(they really show how true "garbage in, garbage out is"). A badly
maintained translation memory can result in more work than its worth.

I'm actually putting together a project idea to impement nightly testing
and translation memory use at the moment. My intention is to set up a
process on a test machine which gets all the message files from CVS,
runs a battery of tests on them (e.g. do they compile?, are there
missing %s placeholders?), obtains a set of statistics (new messages,
fuzzy etc) and finally runs the messages through a message database (we
have one in Sun which might or might not be open sourced depending on
how licensing issues work out). 

If all goes well I can have the basics of this process going in a few

> 4. Use of machine translation software
> There are some machine translation software around, we heard
> of one person (Antonio?) from the gnome i18n crowd that was working on
> a translation system with esparanto as an intermediate
> language. Please tell us more.
> 5. xml-i18n-tools
> Kenneth was not around when we talked about it.
> Is there some documentation somewhere on a web page?
> 6. KDE tools
> Stephan Kulow from the KDE team was present and demonstrated
> some new KDE tools:
>    xml2pot - turns XML documentation into maintainable .pot files.
>    kbabel - GUI translators tool, can mark partial line changes.
> We agreed that these tools look very useful, and recommend
> using them for gnome translations.
> xml2pot should be used to genarate maintainable .pot
> files for documents, and these pot files should then be
> put on a  status page, so we can monitor the progress.
> How to coordinate with kde? We agreed that there need not
> be some heavy coordination, but recommended that people
> get on eachothers lists. It seems that the information is flowing.
> We were very grateful for Stephans insights and comments
> from his KDE knowledge.
> 7. glossary
> There were no SUN people that could tell about the
> work on a  glossary.

Yes a lot Sun people that could tell you about the work on a glossary
wish they were there too :). Seriously there is good work being done by
people to get it translated. There are still rough edges to it but it
forms a basis on which to build a good reference glossary for
translation. Sun intends to use it when we start doc translation in

> 8. Use of Pango
> Pango is a display toolkit for Unicode. Gnome will eventually
> use Pango (2.0?). It seems that there is no need to force everybody to
> use UTF-8 for their .po files, although it should be the end goal.
> 9. What features do we need in gettext?
> Can we make gettext more helpful to translators?
>     eg msgid "file \[noun\]"
>         msgid "file \[verb\]"
> Both giving a hint to the translator on what is meant,
> and also prepared for machine translation. text in \[\]
> should then be ignored when the string is written.
> We recommended a wrapper function to gettext, with
> a macro name of Q_() for this. It should probably be a wrapper
> function, so gnome was not dependent on the new gettext library.
> But it could be implemented in gettext too.
> Another idea for gettext is that is should be able to
> extract messages from other languages than C (and XML).
> Kenneth had an idea about this be done in an easily extensible
> way. Kenneth can you post your ideas to the list?
> We discussed a short list for this, including perl and python,
> xml, what more?
> 10. localizing images
> There was a problem with localizing images. Some images
> are localization dependent, like the "you have mail"
> american mailbox, or the old Swedish "full stop" sign.
> This could be easily implemented by adding the locale name
> to the image in question, and Robert Brady
> volunteered to hack this quite soon.

I think some guidelines on what makes a bad i18n'd image would be very
useful here (for example _never_ use anything with a hand gesture in it,
the gesture is always rude somewhere in the world :).

> Sometimes there is a need to make artwork for localization, eg
> sorting in Danish is a-å, in Swedish it is a-ö - which
> sometimes is put on an image button. We recommended that
> such strings should be sent to the people doing the artwork.
> 11. keyboards
> Somebody mentioned problems with keyboards.
> Keld mentioned that he had done xkbd for danish,
> norwegian, swedish and finnish, that covered all of 8859-1
> with strokes from the keyboard, and could help others
> with their national keyboards for X.
> 12. Guidelines for translators.
> We have some now on the gnome web, but they are very
> limited and somewhat outdated. People are urged to come forward
> with more documentation on this. It is simple, you just upload
> it to the CVS. But please present and discuss it on the list
> first.

Well there are the styleguides we placed in gnome-i18n which can be

> 13. Release policies
> We need a freeze on the translatable strings something like
> 2 weeks before the release. We need to communicate this to the
> responsible for the release and get this nailed down.
> 14. Make gnome a success - organization
> We takled about how to organize the work, this was done
> differently in the different countries.
> In Denmark there is a group of say 15 persons, that translate
> gnome, but also kde, gnu, redhat, mandrake and other things.
> The group also does other language oriented things, like
> doing a wordlist for spellchecking of 530.000 words, a
> list of english/danish translations of 600 words, discussion
> of apis, holding seminars, discussion of i18n standards, talking
> to politicians and people in public administration, writing
> letters to newspapers and more. We meet physically about once a month.
> The group's aim is to make Danish Linux succeed in the marketplace.
> In Sweden the group is about 10 people, but only Gnome.
> The Swedish terminology is decided by a government supported group.
> Norway is just one person for Gnome.
> Germany has a group of people, but only for Gnome.
> UK had only one gnome translator.
> We recommended that the gnome translators in each country
> /language take contact to translators of other open source
> software, and try to help coordinate translations.
> In this way we posslbly can develop an open source platform
> with some consistency in the terminology, so that we can
> minimize the confusion of users, which may be presented
> with different terminology for the same concept in different
> parts of the software platform.
> 15. Non-translatable stuff, like ximian packages
> Kenneth may email us something about this.
> 16. Package maintainer guidelines for helping translators
> Kenneth may email us something about this.
> 17. management/statistics for .po
> Kjartan and Keld looked at their status page sofware,
> and found that it seemed to be OK. Some asked for easy
> download of the latest .po files, and support for that
> will be integrated in the status files Real Soon Now(TM).
> Kind regards
> Keld
> _______________________________________________
> gnome-i18n mailing list

keep up the good work,

Michael Twomey
These opinions are my own and do not represent Sun unless otherwise
Sun Microsystems, Dublin, 8199164, x19164
"Fly my little Makefiles! Fly!"

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