l10n approach for bzr

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 17, 2008, at 3:30 PM, John Arbash Meinel wrote:

> 1) I fully agree that we don't want to leave the strings as is and  
> just
> happen to correct the English at the appropriate time. So "Branch a
> bazzar branch" should indeed be fixed directly.
>
> 2) Indirecting through IDs does have an appeal. It certainly makes it
> clearer that you are using ids and where the "correct" place to fix  
> them is.
>
> 3) However, IDs make the code a bit harder to read.  You need to use
> them everywhere, and then you don't actually know what they are  
> saying.
> One of the key places we will be doing this sort of thing is in
> bzrlib/errors.py

Yep.  English strings just make the code much easier to read.  It's  
unfortunate, because I agree that there's an appeal to using message  
ids.

> In errors.py, though, I think we might actually want to wait to
> translate until just before the exception is displayed. So rather than
> doing:
>
> class MyError(BzrError):
>
>  _fmt = i18n("My Error says %(foo)s")

Please, please, please use PEP 292 strings!  You'll save yourselves  
lots of headaches from translators who leave off the trailing 's'.   
$foo is so much easier for them to get right than %(foo)s.

BTW, I've been musing about a source string format that went something  
like this:

mymsg = _('563:User $user is subscribed to list $listname')

So you the extractor matches (P<msgid>\d+):(P<english>.*) and of  
course the runtime _() function would do the same.  Maybe you can get  
the best of both worlds that way?

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkfe3gYACgkQ2YZpQepbvXEZAwCdGzCajzYfPdC4m8xK4L/vuw/g
+foAnjNIl/wjq+/IP1oMzZeZeRLa4wqv
=QxmU
-----END PGP SIGNATURE-----