Re: mlmmj Spanish translation

[Joel Aelwyn <joel@lightbearer.com>]

[-- Attachment #1: Type: text/plain, Size: 4686 bytes --]

Marcelo E. Magallón wrote:
> On 10/11/05, Mads Martin Joergensen <mmj@mmj.dk> wrote:
> 
>>* Marcelo E. Magallón <marcelo.magallon@gmail.com> [Oct 11. 2005 15:49]:
>>
>>>>The Danish and German translations don't use UTF-8 encoding for the
>>>>extended ASCII characters, so I didn't either.
>>>
>>>That's wrong.
>>>
>>>mlmmj won't do anything with the text it reads from the files
>>>coding-wise, so it's certain that using UTF-8 characters without
>>>including *some* header to that effect will break a system somewhere.
>>
>>That's why they're not UTF-8?
> 
> 
> I meant any non-ASCII characters.  Enrique's files are ISO-8859-1 (or
> -15, whatever) and they will lead to the same kind of trouble.  You
> need a header that states that the body of the email is binary-encoded
> and that the charset is ISO-8859-1.  The files I sent initially did
> exactly this because you can't rely on the MTA to add such headers.

Oy. Yes. Please, please, PLEASE. This is the entire reason for the various 
standards that got written. If it's not US-ASCII, then it needs a Content-Type 
which declares a charset (and potentially the supporting pieces). That 
includes UTF-8 (which I prefer, strongly, but even so it needs to be declared; 
the RFCs are fairly clear about this one, folks - no declaration means 
US-ASCII, any character with the eighth bit set pretty much has an undefined 
behavior, IE, the mailer can do anything it wants - throw it away, try to 
autoconvert it, rearrange it into poetry...)

The correct answer is to use the MIME standards. That's why they were written. 
I know some people on here seem to be allergic to MIME, but honestly, if you 
are? Write in US-ASCII. That's the price of wanting to avoid the 
oh-so-terrible extra bits. It'll compress better anyway if someone ever 
archives it, too. :)

> More problematic is this:
> 
>     Subject: Órdenes disponibles para $listaddr$
> 
> because the encoding of the subject has to be embedded in the subject
> line itself ... which is exactly what the files I sent did and Enrique
> dutyfully broke.

See above. There are standards covering this quite well, already. They should 
be used.

> Marcelo
> 
> PS: I do have objections to the "improved" translation, but the crux
> of the them lies in the differences between Spanish as spoken in Spain
> and Spanish as spoken in the rest of the world, so I'll just let that
> one slip by.  Just as an example, the proper English translation for
> the subject line I'm quoting is "Available orders for $listaddr$"
> instead of "Available commands for $listaddr$".

This would be why es_ES and es_MX (what I've usually seen used to cover most 
of the variants spoken in the Americas, since there isn't a country code for 
'North and South America'...) exist, yes? Much like, oh, en_US and en_GB (and 
en_CA and en_AU, eh, mate?)

The things listed under 'en' or 'es' should be as absolutely neutral as 
possible, which generally means it will sound 'stilted' or 'simplified' to the 
speakers of *all* dialects of the language. "Under the hood" or "under the 
bonnet" is really "in the engine compartment", "the boot" or "the trunk" is 
"the (luggage|cargo) area" or possibly "the rear of the vehicle" (which is not 
a "car", "lorrey", "cab", or "auto", and probably shouldn't be an "automobile" 
though that's more acceptable). And unless you're in San Francisco, a 
"trolley" is also to be avoided.

You'd never guess that I was born in Texas, grew up in Kansas, lived in North 
Carolina and California, and have roomed with Brits, Canadians, and 
Australians, now would you? :) Seriously, though. If it's es_ES, call it that. 
If it's es_MX, call it that. The generic 'es' (or 'en') is just that - 
generic. It will sound 'bad' because it strips out all possible dialect 
nuances, and those arise entirely because they represent meaningful 
distinctions in that dialect. "Orders", "commands", "instructions", 
"directions", and "directives" all mean subtly different things just in en_US 
(and usually several *other* subtly different things in other en_* dialects). 
And, oddly enough, the use of 'commands' is sufficiently traditional *in a 
technical vocabulary* that it can potentially override the normal word 
selection simply by weight of it's own subcultural traditions - so the best 
answer might well be to use a literal analog of 'commands' even though it 
isn't as graceful or sensible as some other alternatives in some languages. 
After all, there are (arguably) more graceful or sensible alternatives in it's 
origin tongue. :)
-- 
Joel Aelwyn <joel@lightbearer.com>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]