Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Sat, 22 Jun 2013 20:46:02 -0400
From: Dave Angel <davea@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: n00b question on spacing
References: <CAJ=2b07ETuSuo2+3Xu6vMOJA+q1JwUFTezO3LaYLG8wXd+FLBQ@mail.gmail.com> <51C4D2FF.8000709@digipen.edu> <mailman.3692.1371908252.3114.python-list@python.org> <51870913-c348-4807-bc25-aa7c8fbf0001@googlegroups.com> <CAPTjJmotX6GWyA_VV3FKvxTMBp2OZT6nOk=1PSvyR6veg1Ek_w@mail.gmail.com> <51C63334.2080805@davea.name> <CAPTjJmoVsJ6ZkDfbG=Yzvh28_0oUSojFG6gXmm7q=5stDLt_Ew@mail.gmail.com> <51C639A5.5070600@davea.name> <CAPTjJmrB9VYBXqyO5eXXHKVM2g=o+GgYi7rh4sw0E9ETh7XtEA@mail.gmail.com>
In-Reply-To: <CAPTjJmrB9VYBXqyO5eXXHKVM2g=o+GgYi7rh4sw0E9ETh7XtEA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3717.1371948377.3114.python-list@python.org>
Lines: 60
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:48960

On 06/22/2013 08:27 PM, Chris Angelico wrote:
> On Sun, Jun 23, 2013 at 9:56 AM, Dave Angel <davea@davea.name> wrote:
>> On 06/22/2013 07:37 PM, Chris Angelico wrote:
>>>> On the contrary, i18n should be done with config files.  The format
>>>> string
>>
>>
>> **as specified in the physical program**
>>
>>
>>>> is the key to the actual string which is located in the file/dict.
>>>> Otherwise you're shipping separate source files for each language --
>>>> blecch.
>>
>>
>> What I was trying to say is that the programmereze format string in the code
>> is replaced at runtime by the French format string in the config file.
>>
>> But the language is missing the indirection I described.  So you have to use
>> a (function or whatever) wrapper to look up the actual format string in the
>> config file.  My point is by making that file equivalent to a dict, you get
>> to have an executable program in "programmereze" before creating any config
>> files, but still able to handle any real language with one config file per
>> language.
>>
>> This is much preferable to the usual numeric lookup, where somebody
>> specifies the 17th format string to be used at this place in the code. Even
>> when you use C++ names, they're still only a crude approximation to the real
>> purpose of the string.
>
> What you're saying is that there are ways to ameliorate the problem
> with i18n. What that means is that you broadly agree with my main
> point, which is that the format string should be kept as close as
> possible to the arguments. When you're NOT translating to multiple
> languages, the string-literal is the most appropriate way to lay this
> out, imo.
>

Absolutely (very broadly).  And when I am, it's still a string literal, 
just not the one the customer will see.  It still should be next to the 
arguments of the format. I'd be replacing something like:

line = "Customer's name: {%0}, address {%1}".format(args)

with

line = i18n(current_language, "Cussom's name: {%0}, addr {%1}", thename, 
theaddr)

And the English config file would look like (not counting any escaping 
or whatevers):

#SIG - American English, headerline
Cussom's name: {%0}, addr {%1}
    Customer's name: {%0}, addr {%1}

The key has the misspelling's and approximations, while the value has 
the actual string to be used as the object of format.
-- 
DaveA