Re: minutes from GUADEC2 translation BOF

[Michael Twomey <michael twomey ireland sun com>]

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 keld@dkuug.dk
> #, reviewed 2001-04-06 keld@dkuug.dk
> #, 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
weeks.

> 
> 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
particular.

> 
> 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
used.

> 
> 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
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n

keep up the good work,
	mick

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