RE: svn commit: r39197 - trunk/subversion/libsvn_ra_svn

> -----Original Message-----
> From: dglasser_at_gmail.com [mailto:dglasser_at_gmail.com] On Behalf Of David
> Glasser
> Sent: woensdag 9 september 2009 2:32
> To: dev_at_subversion.tigris.org
> Cc: svn_at_subversion.tigris.org
> Subject: Re: svn commit: r39197 - trunk/subversion/libsvn_ra_svn
>
> What is the i18n implication of these changes?

There are two changes here:
* Remove the assumption that err->file != NULL. This value is documented that it can be NULL and would raise an Assertion. (This is the reason I started looking)
(My guess is that this is the assertion reported a few times on the user list. This issue was why I started looking)

* The assumption that a client can translate an error code in a message is flawed.

>
> With this change, will "msg=NULL" and "msg!=NULL" errors be in the
> same language, or might they end up different?

This will only work for the specific set of messages compiled in the specific version of the client. (This subset might have the localization issues you are talking about).

But:
* APR error codes are platform specific and only translatable in text on the original server; we pass these as subversion errors.
* Subversion can define new error codes/messages over minor versions. (All error codes added after 1.0 are in this category)

These two groups, containing at least several thousand error messages would show up as something like 'unrecognized error code 123456', with no clue on where to translate that in something resolvable, unless the two operating systems and client versions are compatible.

I think we should focus on finding another way of helping the localization on the client; but we can't just drop the textual error from the originator. (At least not for the non-subversion caused errors).

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2392810
Received on 2009-09-09 11:28:19 CEST