Promoting greater integration between developers/writers/I18N :)



Hello all,

Christian Rose gave a very interesting presentation at the I18N BOF at
Guadec last week. I felt that this gave us a great opportunity to
promote greater integration between developers/writers/I18N, as outlined
in the proposals below.



TOPIC ONE
=========
A lively discussion arose about the best way to handle errors found in
the po files by translators. One translator said that he added an extra
comment in the po file itself, immediately before each such error, and
sent the commented po file back to the developer. The developers seemed
to prefer to have bugs logged in Bugzilla. 

I suggested a combined approach: 
 o The translator opens one Bugzilla bug for each po file, and 
    lists in that bug all of the problems found in that po file.
 o The translator adds the Bugzilla bug number to the po file.

This approach gives all translators immediate access to the problems
found by previous translators, reducing duplication of effort. When the
bug is logged in Bugzilla, both translators and developers can easily
track the bug. 

Writers could follow a similar approach when they find problems in the
UI, as writers are usually the first "users" to examine every aspect of
the UI.


What do you think? Would developers prefer to have multiple problems
logged in a single bug, or one bug per problem?



TOPIC TWO
=========
Of course, ideally we should try to minimize the number of errors in the
first place :)

Among other topics, Christian outlined the problems that translators
face when translating system messages. I suggested that the developers
should:
  o Read the "Writing for Localization" chapter of the GDSG, to avoid
     common I18N pitfalls when writing the system messages.
  o Ask their friendly documentation buddy to review the system
     messages, because:
     - Writers can point out text that is difficult to translate. 
     - Writers can also advise when error messages are too long or too
        short, and provide alternative suggestions.


What do you think of this proposal? 



TOPIC THREE
===========
Another discussion featured the problem of how to translate non-ASCII
characters. One example given was the copyright symbol. I didn't realise
at the time that the BOF was developer-focussed only, or I would have
suggested that the translators could consult their writer colleagues to
see how this is done for documentation translations. But perhaps I am
misunderstanding the problem?  As coincidence would have it, Sasha sent
a mail last week that included an excerpt from a mail that he originally
sent in February 2002 -- perhaps this could help to solve the problem?
"
> ----------------
> Hi guys:
> Gnome Doc Project needs help with localization of stylesheets that will
> be used by GNOME 2 for on-the-fly DocBook->HTML conversion. Obviously,
> all text which the stylesheets put, say, on the titlepage (such as
> "Authors") needs to be translated. So please help us by adding
> localization for your language to the file 
> 
> CVS:gnome-docu/gdp/xsl/l10n.xml
> 
> File syntax is obvious. Just note that non-ascii characters must be
> encoded as unicode character entities, e.g. Ͽ 
> You can use "recode" to convert the file to this format (details --
> inside the file). 
> 
> Yes, I know it is a pain. But this is the way XSL stylesheets are
> localized; if you have comments or suggestions, send them to Norman
> Walsh, not us - our stylesheets are just customization layer on top of
> his. 
> 
> Thanks!
> 
> Sasha Kirillov <kirillov math sunysb edu>
> 
> PS. When replying to this message, please cc gnome-doc-list gnome org 
> ----------------
"

Again, I might be misunderstanding the problem, or the information from
Sasha might now be out of date. I'm also not sure whether translation of
docs is performed by people on the gnome-doc-list or those on the
gnome-i18n-list, so apologies if I'm completely missing the point here.



Perhaps I should have split this mail into three, one for each topic,
but I didn't want to overload your mailboxes :)




Regards,
Breda.



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