gender voice variants
Karen.Broome at am.sony.com
Thu Dec 20 19:49:35 CET 2012
I guess my perspective is as someone who is used to static design templates with sets of localized string data for each applicable locale – much like Mark’s example. I have the English string, I create the localizations I need across various languages, including possibly sex-based strings in the locales where this is appropriate and within my marketing budget. In most cases, this is easily done by the same translator I’ve already hired for that locale.
I assign these multilingual sets to a variable or data element in a *neutral* template that spans all locales and key off user data to display the right string. If the ability to handle sexual variation is not at the language tag level, I can’t simply swap out strings depending on who the audience is. That’s what I was indicating felt clean about handling this in a language tag rather than requiring an additional bit of logic to show the right string for every locale where human sex affects speech. (Or more likely, you just skip this and use the male variant – because it hasn’t been made easy by putting this in the language tag.)
I don’t think the tags should identify parameters of the linguistic audience, but each member of an online audience can also be assigned a language tag, which can then be matched to appropriate content. Dynamic data is the target for this.
From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of Mark Davis ?
Sent: Thursday, December 20, 2012 9:56 AM
To: Michael Everson
Cc: ietflang IETF Languages Discussion
Subject: Re: gender voice variants
The world is rarely "clean" in that sense. The distinction between en-CA, en-US, and en-GB is not clean (look at the usage of the Oxford comma, which cuts across this; let alone the Shatner comma ;-). Nor are the current variants "clean" in the sense of always being algorithmically determinable.
However, certain distinctions even if not perfect, are often extremely useful.
Karen just mentioned "I can't make a use case for your creating formal and informal versions of an OS". In response, I gave an example of a very real use case. And while it may perfectly represent the nuances of expression possible with human language, it does solve a significant issue in IT.
However, I'm not pushing for registration of the formal/informal distinction with BCP47 variants. "Usefulness in IT" unfortunately seems to have little weight as a criterion for registration of variants, so if we decide we need to have it, we'd take the route of proposing a -u or -t subtag instead.
— Il meglio è l’inimico del bene —
On Thu, Dec 20, 2012 at 2:22 AM, Michael Everson <everson at evertype.com<mailto:everson at evertype.com>> wrote:
On 20 Dec 2012, at 02:01, "Broome, Karen" <Karen.Broome at am.sony.com<mailto:Karen.Broome at am.sony.com>> wrote:
>> The problem comes in when you have shared online components. You really don't want to mix du and Sie on the same page, addressing the same user.
> This. So you want this to be in the language tag. Keeps it clean.
Levels of politeness in pronominal and verbal structures is not binarily "clean" in the world's languages. "Formal" and "informal" is not adequate, if you want to argue for opening a floodgate.
Michael Everson * http://www.evertype.com/
Ietf-languages mailing list
Ietf-languages at alvestrand.no<mailto:Ietf-languages at alvestrand.no>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ietf-languages