[sldev] Using llGetAgentLanguage() in a different way...
Alissa Sabre
alissa_sabre at yahoo.co.jp
Tue Jan 27 05:43:58 PST 2009
Two comments on Marine's message and another on Henri's.
Marine:
> - It obviously masks the real language setting. I don't know whether it is
> used a lot or not yet (emphasis on "yet"). As the language is optional,
> scripts have to rely on another way to change their localization anyway.
I believe the llGetAgentLanguage feature is not widely used today. It
is unfortunate. The reason the feature is not widely used is that the
function is too primitive to use in LSL script, especially given a
tight code limit, IMHO.
I hope the mechnism is extended in a future to provide more handy I18N
interface. An example is llSayTranslated("Hello") which automatically
looks for the key "Hello" in a notecard named "fr" in the object where
the executing script is in, and sent the corresponding string taken
from the notecard to a viewer if the viewer's language preference is
"fr".
I consider any idea that conflicts with the original purpose of
llGetAgentLanguage is not good.
Henri:
> I doubt very much many will use that feature at all... For a start, the
> scripter must be able to properly write several different languages... and
> then, if they use different languages in their scripted objects, they also
> will have to write the documentation in the same languages (else it's pretty
> much inconsistant), multiplying the work by as many times as they are
> languages... Economically irrealistic for all but big companies.
Your model sounds like a 20th century, pre-Internet days. :-)
Today, we have Internet and, yes!, Second Life that improve
collaborative effort among _ordinary_ people around the world. The
original developer of a scripted object doesn't need to translate
messages/documets alone. The only thing he/she/they needs to do is
design properly to allow multiple languages. The first product may be
English only, or French, or Japanese. Then, some other residents can
collaborate making the object to work in other languages. Many
popular open source software support a lot of languages. Some of them
support more languages than the similar commercial products developed
by big companies. Why can't we expect similar situation?
I strongly prefer a mechanism that allowss such collaborative
translation/localization in easier ways. The llGetAgentLanguage is
the first step toward the direction.
Marine:
> - Would LL consider "extending" this kind of feature by allowing a viewer to
> upload one custom string (not changed by the user), retrieved by another
> call like this llGetAgentLanguage() function in the future ? Something along
> the lines of llGetCustomString(key id) or llGetSignature(key id), maybe even
> llGetOwnerSignature() that would only work for the owner of the script.
My fundamental question is: what do you want to do with the string
returned by your own viewer? What is the purpose of yo0ur scriot to
identify your own viewer? Depending on the purpose, idea of receiving
viewer-specific string can be good or bad. and if viewer specific
string is essential for what you want to do, I would support the idea
of adding some generic mechanism for scripts to query fo0r such string
to viewers.
Alissa Sabre
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
More information about the SLDev
mailing list