openinteract-dev

[Openinteract-dev] OI2 i18n support

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

As I recently mentioned on the -help list I hope to be doing some 
work in the near future to give i18n support to OI2. This would 
come in two fashions:

  * be able to navigate to a particular page in the document tree 
based on language. So you'd have something like:

    /en/about/company.html
    /ru/about/company.html

And a user requesting:

   http://mysite/about/company.html

would get directed to the right page based on browser or session 
or user settings. One of the reasons I think the '/lang/...' 
setup is useful is security -- you can setup the '/ru/...' tree 
so your Russian folks can have WRITE access only to their docs, 
the '/es/...' tree so your Spanish folks can do their thing, etc.

  * message bundle-type functionality so you can setup a file (or 
database table, or whatever) of keys for substitution in your 
templates:

  # use a key with variable substitution
  <h1>[% msg( 'company.welcome', 'Optiron' ) %]

  # use a key by itself
  <p>[% msg( 'company.intro' ) %]</p>

If you've got experience in this area please chime in with ideas.

Later,

Chris

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

Re: [Openinteract-dev] OI2 i18n support

[Andrew H. <hur...@ll...>]

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...

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 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?

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.

Well, that's enough pre-coffee rambling for this morning.  Sounds 
like a neat setup.
-Andrew


>...
>
>  * message bundle-type functionality so you can setup a file (or 
>database table, or whatever) of keys for substitution in your 
>templates:
>
>  # use a key with variable substitution
>  <h1>[% msg( 'company.welcome', 'Optiron' ) %]
>
>  # use a key by itself
>  <p>[% msg( 'company.intro' ) %]</p>
>
>If you've got experience in this area please chime in with ideas.
>
>Later,
>
>Chris
>
>--
>Chris Winters (ch...@cw...)
>Building enterprise-capable snack solutions since 1988.
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?   SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>openinteract-dev mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-dev

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.

Re: [Openinteract-dev] OI2 i18n support

[Andrew H. <hur...@ll...>]

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

Ah, makes sense now.

>....
>
>>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.


The only possible problem I see, is that this could be solving a 
non-existant problem.  It would be neat to be able to restrict 
documents to users based on language, but how often would that be 
needed?  Even on multi-language discussion boards, I don't see a 
reason for not letting people know about the other boards...

-Andrew


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

Re: [Openinteract-dev] OI2 i18n support

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

* Andrew Hurst (hur...@ll...) [031030 13:52]:
> The only possible problem I see, is that this could be solving a 
> non-existant problem.  It would be neat to be able to restrict 
> documents to users based on language, but how often would that be 
> needed?  Even on multi-language discussion boards, I don't see a 
> reason for not letting people know about the other boards...

Absolutely. I'm much better about keeping things simple than I used to
be, so I doubt I'd implement this until I had a good reason.

Chris

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