Difference between revisions of "Talk:LlGetAgentLanguage"

From Second Life Wiki
Jump to navigation Jump to search
Line 2: Line 2:
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. --[[User:Peter Stindberg|Peter Stindberg]]
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. --[[User:Peter Stindberg|Peter Stindberg]]


== Not in love with this ==
"pt" is Portuguese, not Polish.
"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).
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.--[[User:Tofu Linden|Tofu Linden]] 12:03, 6 July 2008 (PDT)
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.--[[User:Tofu Linden|Tofu Linden]] 12:03, 6 July 2008 (PDT)

Revision as of 11:12, 6 July 2008

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)