Re: [Openinteract-dev] OI2 i18n support

[Chris W. <ch...@cw...>]

Andrew Hurst wrote:
> No real direct experience, but we talked a lot about how to do this in 
> Scoop..  The general consensus was pretty much what you have below.  Key 
> phrases will be in a lookup table with keys and a column for each 
> language.   Then you could insert it into a template with
> 
> [% msg('company.welcome', 'Russian' ) %]
> 
> Which is what you have below, though I've not heard of the term Optiron 
> before...

Sorry, I wasn't clear. The extra arguments are for interpolation 
into the tag's message. Using the Java message bundle properties 
format you might have:

resources_en.properties
----------------------------------------
company.welcome = Welcome to %1

resources_es.properties
----------------------------------------
company.welcome = Bienvenido a %1

So the 'Optiron' in my example -- which is my day job :-) -- 
would get interpolated into %1 when the message is placed.

The correct bundle would be chosen based on the language grabbed 
from the user's browser, from a user selection (stored in a 
cookie or session), or from the user's 'language' preference (if 
the user is logged in). That decision on what language is valid 
for the current request will be overridable so you can choose 
your own.

> But regarding your other feature, with /ru, /es, or whatever based on 
> the language.  You talk about each language only having write access to 
> their own documents (if you set it up that way I would assume). How 

Right, you'd still have to use the normal security setup so that 
'/ru' would be writable by a group 'russian-editors' or something 
like that.

> would you tell what language a particular document stored in the db is 
> in?  Another field?  So now most base tables and most package tables 
> would need to handle another field and check for it?

Good question, I haven't thought about this. My initial intent 
with documents was to provide a transparent way to use a single 
URL to refer to multiple documents depending on the language. 
(You could also use '/ru/about/company.html' so you can send a 
particular URL to someone and get a predictable result.)

> I think it would be handy, if you could work some of that SPOPS magic 
> and have SPOPS know how to handle added language fields.  So you could 
> add a 'lang' key to the hash we'd pass to SPOPS, and it would know to 
> restrict results to that language, but only if we configured it that 
> way.  This would require the aforementioned field in each table, I would 
> think.
>
> This would be beneficial in that it would act like the SPOPS security 
> actions, where the other rows don't exist if you don't have access to them.

Hmmm... very interesting. I could see adding this as a behavior 
as well ('localizable' or something like that), which overrides 
'fetch' to use the given language as another criteria.

Later,

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.