Re: gtranslator queries/feedback

[Keld Jørn Simonsen <keld dkuug dk>]

On Mon, May 28, 2001 at 04:43:58PM +0200, Fatih Demir wrote:
> hm, some simple thoughts about gtranslator which need feedback:
> 
> 2) Wishlist? I didn't hear any wishes till now, so I could think
> 	you're all wishless happy; but this isn't so I guess. What
> 	 are your expactations.

There were some wishes in the minutes from the GUADEC BOF, here they
are for your inspiration :-)  /Keld


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.


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.

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. 

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.

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