Re: Promoting greater integration between developers/writers/I18N:)

Hi Mark,

Mark McLoughlin wrote:
> Hi Breda,
> On Thu, 2003-06-26 at 12:24, Breda McColgan wrote:
> > =========
> > A lively discussion arose about the best way to handle errors found in
> > the po files by translators.
>         We're talking about typos, wrong terminology and i18n issues, right ?

Yes. Also, messages that are too long or too short.
There might be other issues too, Christian did not have time to finish
his presentation :(

> [snip]
> > What do you think? Would developers prefer to have multiple problems
> > logged in a single bug, or one bug per problem?
>         Trivial problems should be logged altogether in a single bug, harder
> problems should have individual bugs.
>         One problem I have as a maintainer is who should I take as having the
> final word on such things e.g. if some piece of terminology is changed
> in a UI review, a translator suggests that some other terminology is
> better and then a writer comes along with a different suggestion. In
> that case, I don't want to have decide myself - I'd like to be able to
> cc a single person or alias and say "You guys decide". Who should I cc ?

*Everyone* should use the Recommended Terminology section of the GNOME
Documentation Style Guide (GDSG) for such questions. New terms can be
added, and existing terms updated, as the need arises. The GDSG is
available at the following URL:

> > =========
> > 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.
>         Sure, this makes sense - just like it makes sense for every developer
> to read the HIG. However, its quite likely that a lot of hackers either
> won't read the GDSG/HIG in full, won't understand it fully or will just
> forget what they read.

Don't you guys read these guides every few months, just to refresh your
memory? ;-P

>         The HIG guys are thinking of doing a quick checklist type thing for
> developers. It would perhaps be better if we had a combined checklist
> thing for issues relating to usability, a11y, i18n and documentation
> with pointers into each of the individual guides for more information.

Sounds good.

> >   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.
>         I'm not exactly sure of what you mean by "system messages". Do you mean
> messages in error/warning dialogs or messages printed to the console. If
> its the latter I'm not sure we even consistently mark them for
> translation :/

I'm talking about the messages that are in the po files. I'm not sure
how you decide what to put in that file. (I'm not a translator, so I'm
not very familiar with the contents of such files.)

>         I'm also not sure how to work it so that hackers would get messages
> reviewed ... I don't think developers typically put, or even want to
> put, too much thought into the error/warning messages they are writing.
> Its usually a diversion from the task at hand e.g. if you are hacking on
> some feature, you don't want to spend much time on error conditions ...
> I'm not saying that is ideal, I'm just being realistic about it :-)

That's why I'm encouraging developers to work more closely with their
colleagues in the documentation and I18N teams, so that we can all work
together to:
- Enhance the user experience in using the GNOME Desktop, applets, and
- Contribute to the GNOME Desktop being the desktop environment of
   choice for users worldwide.
to quote from the presentation given by my colleagues Pat, Irene, and
Eugene last week :)


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