Talk:LlGetAgentLanguage

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

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 but I'm not in a position where I can do anything about it. 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)