Talk:LlGetAgentLanguage

Privacy Concerns

A user probably does not want to give away his nationality/native tongue to any script just based on the fact that this is the language the UI runs in. The native tongue and thus in many cases the geographical location is a rather personal piece of data. ---Peter Stindberg

See the first caveat. -- Strife ^{(talk|contribs)} 10:38, 29 August 2008 (PDT)

Not a failsafe way

Though I welcome this fucntion, it is not a failsafe way to determine the actual users native language, as many people prefer to use the "original" (= English) version of software. If you intend to make localized menus for the user, it would also be a good idea to offer a manual choice. --Peter Stindberg

That's my concern, too.--Boroondas Gupte 04:00, 11 July 2008 (PDT)

But does it need to be failsafe? Isn't that just a possibility for example to serve a cutomer in a language he/she understands? I think this is a good solution. Noone would choose a viewer language he doesn't understand. Too many problems. So if somebody chooses "German" as viewer language he will be able to understand, I think. My problem is: the compiler doesn't understand the command by now. ---Smoere Broek 19 September 2008

Not in love with this

"pt" is Portuguese, not Polish.

I don't think this is a well-designed API. The name of the skin directory is an implementation detail (and not logically consistent in itself, i.e. pt being a standard language code vs en-us being language+country). This should be renamed to something less misleading, or return JUST the underlying language codes before they get turned into silly viewer dir names.

Furthermore, I suspect this is a very blunt instrument for practical purposes - it requires iterating through all users who may be interested in a particular message and dealing them up the right string. Imagine a script with says stuff on channel zero, etc - really impractical. It seems significantly more effective (and as a side effect, privacy-preserving) to allow the various localizations of user-facing strings from scripts to be bundled together (into some kind of marked-up metastring) from script through the viewer and let the viewer extract the appropriate language for presentation.--Tofu Linden 12:03, 6 July 2008 (PDT)

The "pt" description is my fault, I could have sworn that pt was Polish. *sigh*

It's not actually language+country, it's language+dialect. We can't drop dialect support, if we do we insult a huge population, China. Without dialect support we cannot tell the difference between Simplified (SC) and Traditional Chinese (TC). Some brief history, SC is a new set of Chinese characters that were created by the Chinese government to aid in teaching people how to read; with time SC has slowly drifted away from TC and have become separate dialects. Someone who can read TC cannot necessarily read SC and vice versa.

Anyway it is easy to extract the base language code, llGetSubString(llGetAgentLanguage(user), 0, 1).

I wished they had used 3 character language codes (ISO 639-3) instead of 2 character codes (ISO 639-1); I so had my heart set on tlh.

For multi-user environments this is less than optimal I must agree. It would be easy enough to build IM slaves that handled the language code translation automatically. Each slave would have a complete set of strings, they would do the language code lookup and send the message. Something that should be noted here is the amount of memory that would be required to send multi-language strings. If your script sent a message in 6 languages it would need to build the message into 6 languages; If the message is 512 bytes in length thats 3k of memory. I think what we have done is walked down an evolutionary dead end; we need to stop and redesign.

-- Strife Onizuka 12:38, 6 July 2008 (PDT)

Simplified Chinese and Traditional Chinese are not two dialects, but merely two different scripts. They are both used to write vernacular Chinese, which is largely identical across the Chinese-speaking world for day-to-day conversations (when spoken). The scripts are mutually incompatible, sure, but the language is the same, they do not represent different dialects.

But there are regional terminology differences between users of Simplified Chinese (zh-Hans: China zh-cn, Singapore zh-sg) and Traditional Chinese (zh-Hant: Taiwan zh-tw, Hong Kong zh-hk) when it comes to specific domains, for example computing, gaming, or Harry Potter. For example (not a typical one), the word cache is translated as “缓存” in Mainland China (“slow-save” if you take it really literally) and “快取” in Taiwan (“fast-fetch”, in sharp contrast of what is used across the strait). Same thing with many, many words listed here in Chinese Wikipedia's IT topic auto-convert template.

The Chinese Wikipedia uses automatic conversion between Simplified and Traditional, makes sense because under two different scripts it's the same language.

That said, I kinda feel stupid not to have referenced an existing traditional Chinese translation but instead chose to make up terms on my own (for words like “prim”, can you believe they don't even have “prim” in the glossary?)...

I also think that script authors need to be aware that Linden Labs and third parties may, from time to time, add, remove or change languages (when the skinning project finishes) and thus their script must be prepared to fail, and fail gracefully for unknown language/variant combos.

--Geneko Nemeth, aka Kakurady Drakenar 05:44, 20 July 2008 (PDT)

This only scratches the surface

I think this is but a first pass at a much larger issue. The entire (written) language is but one dimension of a much larger issue of how information is presented to the SL user in a method of their choice. Consider a user who is multi-lingual and developers who are also multi-lingual, but the language set of the each may not have overlap with the other. Or, the overlap might be partial. There needs to be some method of "best fit", or at least there should be an ordered list of preferred languages for the user.

Next, add a dimension where the user might not want information delivered as text at all. Someone with a vision disability might prefer to have sound clips delivered to their interface on mouse-over or touch rather than text. Of course, the language issue applies to these sound clips as well.

This might apply to what textures are used in the case where information is embedded in the texture as well. (This would be a challenge, as now each user could be viewing a different texture for the same object. Not sure if that is possible.)

One solution (but I have no idea how I would design the UI for it) would be to allow the user to specify their (multiple) preferences in an ordered list of some form, while the savvy developer could do the same. The actual data structure could be some form of XML. Some function, like llFindXMLMatch(...) would be needed, but that is a development issue. (Wave, wave, the exercise is left to the student...)

I'm not sure how this would all unfold, but I write this not as a development request, but to provide a starting point for more ideas and discussion.

Barbara.--Barbara Schwarz 21:31, 8 November 2008 (UTC)

A simple comma separated list, ordered by preference, like the http Accept-Language HTTP header would do the trick, wouldn't it? This has the benefit that it will work with the RLV hack --Maike Short 14:27, 1 February 2009 (UTC)

Example Redundancy

the change made to the example is a bit redundant... there is no point checking for something that you will be defaulting to... that said the distinctint between 'en-us' and 'en' is a valide one, particularly giver than different viewers return different values. so I'm only going to remove 'en-us' from the check list, and not the default as 'en-us'
-- Void ^{(talk|contribs)} 20:42, 2 October 2012 (PDT)