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

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)

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)