Re: Should translators change source strings?



Mark McLoughlin wrote:
On Mon, 2005-08-08 at 09:48 -0400, Adam Weinberger wrote:
Absence of po/README.TRANSLATORS will mean that translators have implicit permission to edit the source strings themselves to resolve simple, obvious grammar and spelling errors.

	I think this is mostly fair enough, but I wouldn't like to see a
situation where translators routinely re-phrase messages or chose
different terminology.

Heh, I don't think anybody else would want that either. I'm talking about typos and brainos. Although I'd like to hope that modules maintained by non-English-speakers would put something in README.TRANSLATORS that says something to the effect of "feel free to edit strings into what I intended for them."

	e.g. I could imagine a situation where a translator goes on  a crusade
through nautilus replacing the word "directory" everywhere with the word
"folder" where, in fact, there might have been a long discussion in the
past about which term is most appropriate in that context.

I think the proper phrase here would be "obvious fixes only."

	So, I think it makes sense that the maintainer should be involved
(through bugzilla) with string changes, even just as an arbitrator,
unless its a very obvious typo of some sort. And even with obvious
typos, sending the maintainer the patch with a mail "I've just committed
this obvious fix" is always polite.

Developers have the right to say "don't touch my code!" but I'd hope that most people wouldn't. The more bureaucracy there is in changing strings, the fewer the number of strings that will be changed. Too few controls, and we'd have "xadAmxR0xx0rzx!!!1" prepended to every dialogue message. I think there's an acceptable balance that we can hit.

	Also, I'd hope that translators would be well aware of when string
freezes are in effect :-)

It's like rain. On your wedding day. ::-P

# Adam


--
Adam Weinberger
adamw magnesium net || adamw FreeBSD org
adamw vectors cx    ||   adamw gnome org
http://www.vectors.cx



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