[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Localization of schedule_str() values?

From: Martin v. L÷wis <Martin.vonLoewis_at_hpi.uni-potsdam.de>
Date: 2006-08-28 09:45:52 CEST

Karl Fogel schrieb:
> Should we localize this code in subversion/svn/info-cmd.c:
>
> /* Return string representation of SCHEDULE */
> static const char *
> schedule_str(svn_wc_schedule_t schedule)
> {
> switch (schedule)
> {
> case svn_wc_schedule_normal:
> return "normal";
> case svn_wc_schedule_add:
> return "add";
> case svn_wc_schedule_delete:
> return "delete";
> case svn_wc_schedule_replace:
> return "replace";
> default:
> return "none";
> }
> }

Coming in late here: no, without looking at the code where
this is used.

You should not normally localize single words. Instead, only
ever localize whole phrases. If this was used in a context
like "We are using a %s schedule" (which wouldn't be proper
English), then a translator could not possibly get the translation
right: it would not only be out of context semantically,
but, for many languages, also grammatically. For example,
in this context, in English, the words should be
"a normal", "an adding", "a deleting", "a replacing",
and "no" (although this probably still is not the right meaning
wrt. svn).

There are exceptions, of course. If you have single words
for drop-down menu items, you need to localize them as-is.
Just make then sure that
a) the translator is aware of the context of the message
   (it's a context menu item, and it triggers such and
    such action)
b) gettext won't unify it with another occurrence of the
   same word in a different context. This is tricky to
   achieve (e.g. using different PO files, or annotating
   the message id with a number)

Regards,
Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 28 09:46:45 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.