On Sun, 27 Feb 2005, Julian Foad wrote:
> Erik Huelsmann wrote:
> > The BDB_WRAP macro in libsvn_fs_base is given a partial string to insert
> > into another string which provides context.
>
> The context string is:
> "Berkeley DB error while %s for filesystem %s:\n"
>
> The partial strings for the first "%s" are verb phrases:
> "creating environment"
> "opening 'nodes' table"
> "getting youngest revision (closing cursor)"
> etc.
>
It includes more generic fragments as well, like "fetching changes".
> Do you not think that that combination can be successfully translated? I think
> it probably can be. For example, here is a translation into English with
> different word order, punctuation, voice and tense:
>
> "%s. During this operation on the filesystem %s, Berkeley DB returned the
> following error:\n"
> "An environment was being created"
> "The 'nodes' table was being opened"
> "While closing the cursor, the youngest revision was being sought"
>
>
The capitalization of the "translation" indicates that you assume that the
fragment is used only in this particular place. What if it is used in
another context as well, where capitalization is inappropriate?
> > This is exactly the situation as described in the gettext manual how *not*
> > to do it :-)
>
> I doubt that those instructions were intended to cover situations where a _lot_
> of duplication is avoided and each partial string is a phrase that _can_ be
> translated.
>
The problems with message fragments are always there, regardless how much
duplication it avoids:-)
There is actually a solution to this fragment problem described in the
gettext manual. They are using GUI labels as an example.
YOu can prefix the translatable string with something, like "DB|". Then,
if the string was translated, you just use the translation (which doesn't
include the prefix). If the string wasn't translated (gettext returns its
argument), you just drop the prefix. This disambiguates fragments in
different context. IN general, we should avoid this, but for this DB_WRAP
case, it might be worth it.
HOpe this clarifies,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 28 22:43:52 2005