Mailing List Archive: Catalyst: Users

Multi-language and REST

1 2

View All

Index | Next | Previous | View Threaded

catalyst at iandocherty

Apr 25, 2008, 5:44 AM

Post #1 of 28 (882 views)
Permalink

Multi-language and REST

I have been pondering how to take an existing Catalyst application and
make it multi-lingual.

I would prefer to use a RESTful method, so this would translate /foo/bar
to /en/foo/bar or /fr/foo/bar (for English and French respectively).

The problem as I see it is how to do this. I don't want to move all my
controllers, e.g. MyApp::Controller::Foo::Bar to
MyApp::Controller::Lang::Foo::Bar

What other alternatives are there?

Regards
Ian

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

hovenko at linpro

Apr 25, 2008, 6:08 AM

Post #2 of 28 (861 views)
Permalink

Re: Multi-language and REST [In reply to]

On Friday 25 April 2008 14:44:38 Ian Docherty wrote:
> I have been pondering how to take an existing Catalyst application and
> make it multi-lingual.
>
> I would prefer to use a RESTful method, so this would translate /foo/bar
> to /en/foo/bar or /fr/foo/bar (for English and French respectively).

The elegang solution is to make use of the request header Accept-Language, but
not many users know how to change this setting in their browsers.

http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12

>
> The problem as I see it is how to do this. I don't want to move all my
> controllers, e.g. MyApp::Controller::Foo::Bar to
> MyApp::Controller::Lang::Foo::Bar
>
> What other alternatives are there?
>
> Regards
> Ian
>
> _______________________________________________
> List: Catalyst[at]lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/

--
Knut-Olav Hoven
Systemutvikler mob: +47 986 71 700
Linpro AS http://www.linpro.no/

Attachments:

signature.asc (0.18 KB)

claco at chrislaco

Apr 25, 2008, 6:21 AM

Post #3 of 28 (863 views)
Permalink

Re: Multi-language and REST [In reply to]

Ian Docherty wrote:
> I have been pondering how to take an existing Catalyst application and
> make it multi-lingual.
>
> I would prefer to use a RESTful method, so this would translate /foo/bar
> to /en/foo/bar or /fr/foo/bar (for English and French respectively).
>
> The problem as I see it is how to do this. I don't want to move all my
> controllers, e.g. MyApp::Controller::Foo::Bar to
> MyApp::Controller::Lang::Foo::Bar
>
> What other alternatives are there?
>
> Regards
> Ian

Well, I'm sure there's a somewhat elegant way to do this with Chained,
but it the other controllers don't use Chained now, that could get fun.

The brute force way is to inspect the request and rip out the language
portion before sending it on to get dispatched...just like the Flavour
plugin does with file extensions:

sub prepare_path {}

Attachments:

signature.asc (0.18 KB)

catalyst at iandocherty

Apr 25, 2008, 7:12 AM

Post #4 of 28 (862 views)
Permalink

Re: Multi-language and REST [In reply to]

Knut-Olav Hoven wrote:
> On Friday 25 April 2008 14:44:38 Ian Docherty wrote:
>
>> I have been pondering how to take an existing Catalyst application and
>> make it multi-lingual.
>>
>> I would prefer to use a RESTful method, so this would translate /foo/bar
>> to /en/foo/bar or /fr/foo/bar (for English and French respectively).
>>
>
> The elegang solution is to make use of the request header Accept-Language, but
> not many users know how to change this setting in their browsers.
>
> http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
>
Yes, I have done this previously, it is elegant, but not RESTful and
does not make it easy for users to change their settings on a
site-by-site basis dynamically, as you could if you provided a language
selection box on each page.
>
>> The problem as I see it is how to do this. I don't want to move all my
>> controllers, e.g. MyApp::Controller::Foo::Bar to
>> MyApp::Controller::Lang::Foo::Bar
>>
>> What other alternatives are there?
>>
>> Regards
>> Ian
>>
>> _______________________________________________
>> List: Catalyst[at]lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> List: Catalyst[at]lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>

moseley at hank

Apr 25, 2008, 7:26 AM

Post #5 of 28 (864 views)
Permalink

Re: Multi-language and REST [In reply to]

On Fri, Apr 25, 2008 at 01:44:38PM +0100, Ian Docherty wrote:
> I have been pondering how to take an existing Catalyst application and
> make it multi-lingual.
>
> I would prefer to use a RESTful method, so this would translate /foo/bar
> to /en/foo/bar or /fr/foo/bar (for English and French respectively).
>
> The problem as I see it is how to do this. I don't want to move all my
> controllers, e.g. MyApp::Controller::Foo::Bar to
> MyApp::Controller::Lang::Foo::Bar

I check if the prefix is a valid language (if it's one of the language
files I loaded at startup), if so I then remove it from the request
path and append it to the request base.

--
Bill Moseley
moseley[at]hank.org

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

catalyst at iandocherty

Apr 25, 2008, 7:26 AM

Post #6 of 28 (865 views)
Permalink

Re: Multi-language and REST [In reply to]

Christopher H. Laco wrote:
> Ian Docherty wrote:
>> I have been pondering how to take an existing Catalyst application
>> and make it multi-lingual.
>>
>> I would prefer to use a RESTful method, so this would translate
>> /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French
>> respectively).
>>
>> The problem as I see it is how to do this. I don't want to move all
>> my controllers, e.g. MyApp::Controller::Foo::Bar to
>> MyApp::Controller::Lang::Foo::Bar
>>
>> What other alternatives are there?
>>
>> Regards
>> Ian
>
> Well, I'm sure there's a somewhat elegant way to do this with Chained,
> but it the other controllers don't use Chained now, that could get fun.
I have considered chained, and would be prepared to re-write the
existing controllers. A bigger decision would be renaming the
controllers or moving them.

e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar

To match against /<lang>/foo/bar either I can leave the controller where
it is (lib/MyApp/Controller/Foo/Bar.pm) or move it
(lib/MyApp/Controller/Lang/Foo/Bar)

The first approach is less work (only using chained) the second is more
work, but maps the URI namespace more logically to the Class names.

What would people do if they were writing a Catalyst App from scratch
with this feature? That would tell me what the 'best practice' is even
if it means a big re-write exercise.
>
> The brute force way is to inspect the request and rip out the language
> portion before sending it on to get dispatched...just like the Flavour
> plugin does with file extensions:
>
> sub prepare_path {}
One of my pet peeves is exemplified in the 'Flavour' plugin. It is such
minimal documentation that it neither tells you what it does or why it
does it. OK, I can look at the code, but it is too much effort unless I
think I have a good reason to do so. I assume in this case that it is
something to do with date strings in the URI (for blogging?). I can't be
ar**d!

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

claco at chrislaco

Apr 25, 2008, 7:35 AM

Post #7 of 28 (866 views)
Permalink

Re: Multi-language and REST [In reply to]

Ian Docherty wrote:
> Christopher H. Laco wrote:
>> Ian Docherty wrote:
>>> I have been pondering how to take an existing Catalyst application
>>> and make it multi-lingual.
>>>
>>> I would prefer to use a RESTful method, so this would translate
>>> /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French
>>> respectively).
>>>
>>> The problem as I see it is how to do this. I don't want to move all
>>> my controllers, e.g. MyApp::Controller::Foo::Bar to
>>> MyApp::Controller::Lang::Foo::Bar
>>>
>>> What other alternatives are there?
>>>
>>> Regards
>>> Ian
>>
>> Well, I'm sure there's a somewhat elegant way to do this with Chained,
>> but it the other controllers don't use Chained now, that could get fun.
> I have considered chained, and would be prepared to re-write the
> existing controllers. A bigger decision would be renaming the
> controllers or moving them.
>
> e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
>
> To match against /<lang>/foo/bar either I can leave the controller where
> it is (lib/MyApp/Controller/Foo/Bar.pm) or move it
> (lib/MyApp/Controller/Lang/Foo/Bar)
>
> The first approach is less work (only using chained) the second is more
> work, but maps the URI namespace more logically to the Class names.
>
> What would people do if they were writing a Catalyst App from scratch
> with this feature? That would tell me what the 'best practice' is even
> if it means a big re-write exercise.
>>
>> The brute force way is to inspect the request and rip out the language
>> portion before sending it on to get dispatched...just like the Flavour
>> plugin does with file extensions:
>>
>> sub prepare_path {}
> One of my pet peeves is exemplified in the 'Flavour' plugin. It is such
> minimal documentation that it neither tells you what it does or why it
> does it. OK, I can look at the code, but it is too much effort unless I
> think I have a good reason to do so. I assume in this case that it is
> something to do with date strings in the URI (for blogging?). I can't be
> ar**d!
>
>

It does just what just what Bill suggested.

"I check if the prefix is a valid language (if it's one of the language
files I loaded at startup), if so I then remove it from the request
path and append it to the request base."

In prepare_path.. you inspect the requested path.. yank out the
language.. then pass along the remaining path...which should map to your
existing controllers just fine.

As far as chained goes... I thought there was an example floating around
that has Root::lang as Chained, then all other modules Chaine against
/lang as their root instead of /...

-=Chris

Attachments:

signature.asc (0.18 KB)

autarch at urth

Apr 25, 2008, 8:04 AM

Post #8 of 28 (864 views)
Permalink

Re: Multi-language and REST [In reply to]

On Fri, 25 Apr 2008, Ian Docherty wrote:

>> http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
>>
> Yes, I have done this previously, it is elegant, but not RESTful and does not
> make it easy for users to change their settings on a site-by-site basis
> dynamically, as you could if you provided a language selection box on each
> page.

Why do you say it's not RESTful?

I think it's very RESTful, but it depends on how you think about it. If
the language of the content is basically an issue of "formatting", then
switching language based on a header is perfect. The client provides
sufficient information to produce a correct response _on each request_ as
part of HTTP. This is basically the essence of REST.

OTOH, if you consider each language's content fundamentally separate
things, then each language should have its own set of URIs.

-dave

/*==========================
VegGuide.Org
Your guide to all that's veg
==========================*/

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Apr 25, 2008, 8:05 AM

Post #9 of 28 (863 views)
Permalink

Re: Multi-language and REST [In reply to]

* Ian Docherty <catalyst[at]iandocherty.com> [2008-04-25 16:25]:
> Knut-Olav Hoven wrote:
>> The elegang solution is to make use of the request header
>> Accept-Language, but not many users know how to change this
>> setting in their browsers.
>>
>> http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
>
> Yes, I have done this previously, it is elegant, but not
> RESTful

Please educate yourself about what “RESTful” means before you
make more claims about things not being so.

(Note I’m not saying Accept-Language is the right solution here.
Personally I think content negotiation in HTTP is missing a few
nuts and bolts to make it useful for non-trivial uses (which is
basically synonymous with “in human-operated browsers”).)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Apr 25, 2008, 8:20 AM

Post #10 of 28 (864 views)
Permalink

Re: Multi-language and REST [In reply to]

* Ian Docherty <catalyst[at]iandocherty.com> [2008-04-25 16:35]:
> I have considered chained, and would be prepared to re-write
> the existing controllers. A bigger decision would be renaming
> the controllers or moving them.
>
> e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
>
> To match against /<lang>/foo/bar either I can leave the
> controller where it is (lib/MyApp/Controller/Foo/Bar.pm) or
> move it (lib/MyApp/Controller/Lang/Foo/Bar)
>
> The first approach is less work (only using chained) the second
> is more work, but maps the URI namespace more logically to the
> Class names.
>
> What would people do if they were writing a Catalyst App from
> scratch with this feature? That would tell me what the 'best
> practice' is even if it means a big re-write exercise.

I use Chained exclusively and don’t use the Perl package
namespace as a mapping to the URI namespace at all, only
for logically grouping related functionality. Usually the
two still correspond to some extent of course, but I don’t
feel any need to force a correspondence.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

catalyst at iandocherty

Apr 25, 2008, 8:55 AM

Post #11 of 28 (860 views)
Permalink

Re: Multi-language and REST [In reply to]

Dave Rolsky wrote:
> On Fri, 25 Apr 2008, Ian Docherty wrote:
>
>>> http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
>>>
>> Yes, I have done this previously, it is elegant, but not RESTful and
>> does not make it easy for users to change their settings on a
>> site-by-site basis dynamically, as you could if you provided a
>> language selection box on each page.
>
> Why do you say it's not RESTful?
>
> I think it's very RESTful, but it depends on how you think about it.
> If the language of the content is basically an issue of "formatting",
> then switching language based on a header is perfect. The client
> provides sufficient information to produce a correct response _on each
> request_ as part of HTTP. This is basically the essence of REST.
>
> OTOH, if you consider each language's content fundamentally separate
> things, then each language should have its own set of URIs.
Yes, this is exactly what I had in mind. I did not (and still don't)
consider the language of the content as 'formatting', the content for
each language is different (in my mind).

I don't really want this to start another flame-war about RESTful etc.
this point is outside of my original request so I won't respond (on
list) to this off-topic subject any more.

Regards
Ian

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

catalyst at iandocherty

Apr 25, 2008, 9:03 AM

Post #12 of 28 (861 views)
Permalink

Re: Re: Multi-language and REST [In reply to]

Aristotle Pagaltzis wrote:
> * Ian Docherty <catalyst[at]iandocherty.com> [2008-04-25 16:35]:
>
>> I have considered chained, and would be prepared to re-write
>> the existing controllers. A bigger decision would be renaming
>> the controllers or moving them.
>>
>> e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
>>
>> To match against /<lang>/foo/bar either I can leave the
>> controller where it is (lib/MyApp/Controller/Foo/Bar.pm) or
>> move it (lib/MyApp/Controller/Lang/Foo/Bar)
>>
>> The first approach is less work (only using chained) the second
>> is more work, but maps the URI namespace more logically to the
>> Class names.
>>
>> What would people do if they were writing a Catalyst App from
>> scratch with this feature? That would tell me what the 'best
>> practice' is even if it means a big re-write exercise.
>>
>
> I use Chained exclusively and don’t use the Perl package
> namespace as a mapping to the URI namespace at all, only
> for logically grouping related functionality. Usually the
> two still correspond to some extent of course, but I don’t
> feel any need to force a correspondence.
>
I have considered that, but felt that with several developers a 'hard
rule' which mapped the
Perl package namespace to URI namespace avoided potential chaos.

I may reconsider in light of your comment. Would you care to give an
example of
where you would choose *not* to map one-to-one?
> Regards,
>

apv at sedition

Apr 25, 2008, 9:15 AM

Post #13 of 28 (861 views)
Permalink

Re: Multi-language and REST [In reply to]

On Apr 25, 2008, at 8:55 AM, Ian Docherty wrote:
> Dave Rolsky wrote:
>> On Fri, 25 Apr 2008, Ian Docherty wrote:
>>
>>>> http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
>>>>
>>> Yes, I have done this previously, it is elegant, but not RESTful
>>> and does not make it easy for users to change their settings on a
>>> site-by-site basis dynamically, as you could if you provided a
>>> language selection box on each page.
>>
>> Why do you say it's not RESTful?
>>
>> I think it's very RESTful, but it depends on how you think about
>> it. If the language of the content is basically an issue of
>> "formatting", then switching language based on a header is
>> perfect. The client provides sufficient information to produce a
>> correct response _on each request_ as part of HTTP. This is
>> basically the essence of REST.
>>
>> OTOH, if you consider each language's content fundamentally
>> separate things, then each language should have its own set of URIs.
> Yes, this is exactly what I had in mind. I did not (and still
> don't) consider the language of the content as 'formatting', the
> content for each language is different (in my mind).

I agree that it's content, not formatting. If CSS/client-side-JS can
(in a practical fashion) change it, it's formatting, otherwise, it's
content.

While a headers based solution sounds neat, it would cause several
problems. A multi-lingual user, like our friendly neighborhood
Aristotle who surely knows everything I'm saying already, might well
like to have his default/first accept in Swahili but read a certain
resource in Japanese, for whatever reason. Changing browser settings
to see a different resource would be awful UI. Also, the big search
bots would probably only end up indexing one version of your site.

The base/path swap sounds like a great approach.

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

apv at sedition

Apr 25, 2008, 9:20 AM

Post #14 of 28 (861 views)
Permalink

Re: Re: Multi-language and REST [In reply to]

On Apr 25, 2008, at 9:03 AM, Ian Docherty wrote:
>> I use Chained exclusively and don�t use the Perl package namespace
>> as a mapping to the URI namespace at all, only for logically
>> grouping related functionality. Usually the two still correspond
>> to some extent of course, but I don�t feel any need to force a
>> correspondence.
> I have considered that, but felt that with several developers a
> 'hard rule' which mapped the
> Perl package namespace to URI namespace avoided potential chaos.
>
> I may reconsider in light of your comment. Would you care to give
> an example of
> where you would choose *not* to map one-to-one?

I'm in the same camp for the most part. I'll have a
Controller::Article but have its chain root be "a" for the short URIs.

You can also then have C::Admin::Article which doesn't dispatch to /
admin/article but chains from /a/[id]/edit /a/[id]/preview /a/[id]/
rev/[#] and so on. Then a single auto method (if the setup is that
simplistic) in Admin.pm can check authn/authz for everything in it.

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

autarch at urth

Apr 25, 2008, 10:23 AM

Post #15 of 28 (846 views)
Permalink

Re: Multi-language and REST [In reply to]

On Fri, 25 Apr 2008, Ashley wrote:

> I agree that it's content, not formatting. If CSS/client-side-JS can (in a
> practical fashion) change it, it's formatting, otherwise, it's content.

I should have used the word representation. With REST, you'd have the same
URI for one resource, but you might offer it as HTML, JSON, and plain
text based on what the client requests.

Given the Accept-Language header, you could do the same thing with
language.

-dave

/*==========================
VegGuide.Org
Your guide to all that's veg
==========================*/

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

claco at chrislaco

Apr 25, 2008, 10:28 AM

Post #16 of 28 (849 views)
Permalink

Re: Multi-language and REST [In reply to]

Dave Rolsky wrote:
> On Fri, 25 Apr 2008, Ashley wrote:
>
>> I agree that it's content, not formatting. If CSS/client-side-JS can
>> (in a practical fashion) change it, it's formatting, otherwise, it's
>> content.
>
> I should have used the word representation. With REST, you'd have the
> same URI for one resource, but you might offer it as HTML, JSON, and
> plain text based on what the client requests.
>
> Given the Accept-Language header, you could do the same thing with
> language.
>
>
> -dave

Could and should. I've taken the approach using the REST controller that
if anyone wants to get at a resource easier (easier to alter the uri
than the headers), then use the content-type query param. I think the
same should be true for language.

If changing Accept-Language is too much, (or people want to view a
language other than their native), then look at language= in the query
params first..if it's empty...honor Accept-Language... rather than
forcing /<lang>/ at the front of all urls.

Attachments:

signature.asc (0.18 KB)

apv at sedition

Apr 25, 2008, 1:09 PM

Post #17 of 28 (844 views)
Permalink

Re: Multi-language and REST [In reply to]

On Apr 25, 2008, at 10:28 AM, Christopher H. Laco wrote:
> If changing Accept-Language is too much, (or people want to view a
> language other than their native), then look at language= in the
> query params first..if it's empty...honor Accept-Language... rather
> than forcing /<lang>/ at the front of all urls.

I like the idea (and you could even cookie language prefs instead of
a query string solution which would be more expensive/complex with
the URI rewrites) but giving up a large chunk of one's search engine
results for a more purist interface is a pretty high price. As of
last year (haven't checked recently) the googlebot couldn't even
correctly index pages served as application/xhtml. Some bots might do
the right thing with headers for their target language base(s) but I
doubt it's many, if even a minority, of them yet.

It's not a transport issue (like HTML/PDF/JSON/XML/etc) which makes
perfect sense for header control because the clients and client-side
stuff is being written now in tandem, it's different content and the
target clients are laden with legacy behavior. I like PUT and DELETE
too but I'm not going to abandon POST as their stand-in (or fall-
back) any time soon.

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

catalyst at iandocherty

Apr 25, 2008, 1:37 PM

Post #18 of 28 (846 views)
Permalink

Re: Multi-language and REST [In reply to]

Christopher H. Laco wrote:
> Ian Docherty wrote:
>> Christopher H. Laco wrote:
>>> Ian Docherty wrote:
>>>> I have been pondering how to take an existing Catalyst application
>>>> and make it multi-lingual.
>>>>
>>>> I would prefer to use a RESTful method, so this would translate
>>>> /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French
>>>> respectively).
>>>>
>>>> The problem as I see it is how to do this. I don't want to move all
>>>> my controllers, e.g. MyApp::Controller::Foo::Bar to
>>>> MyApp::Controller::Lang::Foo::Bar
>>>>
>>>> What other alternatives are there?
>>>>
>>>> Regards
>>>> Ian
>>>
>>> Well, I'm sure there's a somewhat elegant way to do this with
>>> Chained, but it the other controllers don't use Chained now, that
>>> could get fun.
>> I have considered chained, and would be prepared to re-write the
>> existing controllers. A bigger decision would be renaming the
>> controllers or moving them.
>>
>> e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
>>
>> To match against /<lang>/foo/bar either I can leave the controller
>> where it is (lib/MyApp/Controller/Foo/Bar.pm) or move it
>> (lib/MyApp/Controller/Lang/Foo/Bar)
>>
>> The first approach is less work (only using chained) the second is
>> more work, but maps the URI namespace more logically to the Class names.
>>
>> What would people do if they were writing a Catalyst App from scratch
>> with this feature? That would tell me what the 'best practice' is
>> even if it means a big re-write exercise.
>>>
>>> The brute force way is to inspect the request and rip out the
>>> language portion before sending it on to get dispatched...just like
>>> the Flavour plugin does with file extensions:
>>>
>>> sub prepare_path {}
>> One of my pet peeves is exemplified in the 'Flavour' plugin. It is
>> such minimal documentation that it neither tells you what it does or
>> why it does it. OK, I can look at the code, but it is too much effort
>> unless I think I have a good reason to do so. I assume in this case
>> that it is something to do with date strings in the URI (for
>> blogging?). I can't be ar**d!
>>
>>
>
> It does just what just what Bill suggested.
>
> "I check if the prefix is a valid language (if it's one of the language
> files I loaded at startup), if so I then remove it from the request
> path and append it to the request base."
>
> In prepare_path.. you inspect the requested path.. yank out the
> language.. then pass along the remaining path...which should map to
> your existing controllers just fine.
I have actually taken a look at the Flavour plugin (can't see for the
life of me why it is called that!) and it gives an example of yanking
off the /yyyy/mm/dd at the start of a path, putting the values into
accessors of flavour (e.g. $c->flavour->year) leaving the rest of the
path to be processed as normal. This is pretty much what I want to do
for the language so thanks for pointing out the plugin to me.

I am pretty confident that I can now write a plugin to strip out a
language from the start of a path in the same way.

Looking at the Catalyst best practices, am I going to be polluting the
catalyst namespace by writing this as a plugin? I can't see any
alternative (making it a base Controller is actually what I am trying to
avoid).

Any suggestions as to a namespace for this? Catalyst::Plugin::LangURI
perhaps?
>
> As far as chained goes... I thought there was an example floating
> around that has Root::lang as Chained, then all other modules Chaine
> against /lang as their root instead of /...
I should not need this if I do the above then I can leave my existing
controllers unchanged (and unchained).
>
> -=Chris
>

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

claco at chrislaco

Apr 25, 2008, 1:45 PM

Post #19 of 28 (841 views)
Permalink

Re: Multi-language and REST [In reply to]

Ian Docherty wrote:
> Christopher H. Laco wrote:
>> Ian Docherty wrote:
>>> Christopher H. Laco wrote:
>>>> Ian Docherty wrote:
>>>>> I have been pondering how to take an existing Catalyst application
>>>>> and make it multi-lingual.
>>>>>
>>>>> I would prefer to use a RESTful method, so this would translate
>>>>> /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French
>>>>> respectively).
>>>>>
>>>>> The problem as I see it is how to do this. I don't want to move all
>>>>> my controllers, e.g. MyApp::Controller::Foo::Bar to
>>>>> MyApp::Controller::Lang::Foo::Bar
>>>>>
>>>>> What other alternatives are there?
>>>>>
>>>>> Regards
>>>>> Ian
>>>>
>>>> Well, I'm sure there's a somewhat elegant way to do this with
>>>> Chained, but it the other controllers don't use Chained now, that
>>>> could get fun.
>>> I have considered chained, and would be prepared to re-write the
>>> existing controllers. A bigger decision would be renaming the
>>> controllers or moving them.
>>>
>>> e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
>>>
>>> To match against /<lang>/foo/bar either I can leave the controller
>>> where it is (lib/MyApp/Controller/Foo/Bar.pm) or move it
>>> (lib/MyApp/Controller/Lang/Foo/Bar)
>>>
>>> The first approach is less work (only using chained) the second is
>>> more work, but maps the URI namespace more logically to the Class names.
>>>
>>> What would people do if they were writing a Catalyst App from scratch
>>> with this feature? That would tell me what the 'best practice' is
>>> even if it means a big re-write exercise.
>>>>
>>>> The brute force way is to inspect the request and rip out the
>>>> language portion before sending it on to get dispatched...just like
>>>> the Flavour plugin does with file extensions:
>>>>
>>>> sub prepare_path {}
>>> One of my pet peeves is exemplified in the 'Flavour' plugin. It is
>>> such minimal documentation that it neither tells you what it does or
>>> why it does it. OK, I can look at the code, but it is too much effort
>>> unless I think I have a good reason to do so. I assume in this case
>>> that it is something to do with date strings in the URI (for
>>> blogging?). I can't be ar**d!
>>>
>>>
>>
>> It does just what just what Bill suggested.
>>
>> "I check if the prefix is a valid language (if it's one of the language
>> files I loaded at startup), if so I then remove it from the request
>> path and append it to the request base."
>>
>> In prepare_path.. you inspect the requested path.. yank out the
>> language.. then pass along the remaining path...which should map to
>> your existing controllers just fine.
> I have actually taken a look at the Flavour plugin (can't see for the
> life of me why it is called that!) and it gives an example of yanking
> off the /yyyy/mm/dd at the start of a path, putting the values into
> accessors of flavour (e.g. $c->flavour->year) leaving the rest of the
> path to be processed as normal. This is pretty much what I want to do
> for the language so thanks for pointing out the plugin to me.
>
> I am pretty confident that I can now write a plugin to strip out a
> language from the start of a path in the same way.
>
> Looking at the Catalyst best practices, am I going to be polluting the
> catalyst namespace by writing this as a plugin? I can't see any
> alternative (making it a base Controller is actually what I am trying to
> avoid).
>
> Any suggestions as to a namespace for this? Catalyst::Plugin::LangURI
> perhaps?

If it's just for your app.. put it in MyApp.pm...
If you want to do something for the rest of us...personally... I'd
suggest making this part of the I18N plugin... since it's really just
another way to set the current $c->language...

And...it should be off by default...

Attachments:

signature.asc (0.18 KB)

pagaltzis at gmx

Apr 25, 2008, 2:39 PM

Post #20 of 28 (842 views)
Permalink

Re: Multi-language and REST [In reply to]

* Ashley <apv[at]sedition.com> [2008-04-25 22:20]:
> I like PUT and DELETE too but I'm not going to abandon POST as
> their stand-in (or fall-back) any time soon.

http://search.cpan.org/dist/Catalyst-Request-REST-ForBrowsers/

autarch++

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

jshirley at gmail

Apr 25, 2008, 3:02 PM

Post #21 of 28 (841 views)
Permalink

Re: Multi-language and REST [In reply to]

On Fri, Apr 25, 2008 at 1:45 PM, Christopher H. Laco
<claco[at]chrislaco.com> wrote:
>
> If it's just for your app.. put it in MyApp.pm...
> If you want to do something for the rest of us...personally... I'd suggest
> making this part of the I18N plugin... since it's really just another way to
> set the current $c->language...
>
> And...it should be off by default...
>

I don't like the idea of another plugin, nor do I like the idea of
polluting I18N. Perhaps something that just uses I18N as a baseclass
that is called C::P::I18N::FromURI?

But... as long as it is off by default I guess it could go into I18N...

-J

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

autarch at urth

Apr 25, 2008, 3:02 PM

Post #22 of 28 (842 views)
Permalink

Re: Re: Multi-language and REST [In reply to]

On Fri, 25 Apr 2008, Aristotle Pagaltzis wrote:

> * Ashley <apv[at]sedition.com> [2008-04-25 22:20]:
>> I like PUT and DELETE too but I'm not going to abandon POST as
>> their stand-in (or fall-back) any time soon.
>
> http://search.cpan.org/dist/Catalyst-Request-REST-ForBrowsers/
>
> autarch++

Thanks.

This module illustrates what I'm trying to adopt as a general principle of
my REST development. Browsers suck, but that doesn't mean the internals of
my app need to suck as well. You can design the core of your app using
"strict" REST principles, and then put some shims around the edges to
handle the real world.

This has the side benefit of giving your app a nice clear internal
structure. In my controllers, I still have methods like "user_PUT",
"user_DELETE", "users_POST", etc. If you know REST, you probably have a
_really_ good idea of what those do.

For the language stuff, you could do something like have a plugin that
stripped out a language prefix from the URI early on, and then set
something in the request.

Better yet, you might do something like this:

* check for a URI prefix
* then check Accept-Language

Of course, any sort of URI fixup scheme involves some burden on the part
of the application to generate the right URIs.

-dave

/*==========================
VegGuide.Org
Your guide to all that's veg
==========================*/

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

geir at fandom

Apr 28, 2008, 7:17 AM

Post #23 of 28 (781 views)
Permalink

Re: Multi-language and REST [In reply to]

On 25 Apr 2008, at 14:44 , Ian Docherty wrote:

> I have been pondering how to take an existing Catalyst application
> and make it multi-lingual.
>
> I would prefer to use a RESTful method, so this would translate /foo/
> bar to /en/foo/bar or /fr/foo/bar (for English and French
> respectively).
>
> The problem as I see it is how to do this. I don't want to move all
> my controllers, e.g. MyApp::Controller::Foo::Bar to
> MyApp::Controller::Lang::Foo::Bar
>
> What other alternatives are there?

- Use two different subdomains (en.domain.com and fr.domain.com)

- Send a cookie header (which arguably is easier for the user than
messing with Accept-Language)

- Send both languages in the HTML (encoded with lang="xxx"), but show
only one using CSS

The main question is to decide whether the language should be
specified in the URL or not. There are valid reasons for saying that
the French text is not the same document as the English text, hence
they should have separate URLs (one such example is having both
versions indexed in Google).

-geir

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

telebody at gmail

Apr 28, 2008, 8:39 AM

Post #24 of 28 (782 views)
Permalink

Re: Multi-language and REST [In reply to]

I think other cases show it is not only an i18n issue.

In a business listings site I made I have
x.com/dir/CityName/Business_Services/Advertising for example.

The top level category Business_Services is optional as the secondary
level category name is unique. The CityName could be any city in the
state, or "All_Cities".
No city means All_Cities.
If there is a city but no topic, it shows table of contents for that city only.
A top level topic but no secondary level topic, it shows a blog on that topic.

As Bill Moseley does, after the dir (which is Dir.pm) I check if there
is a valid city.

I also made some experimental tags to modify behavior. So you could
add "/show_all_cities" at the end and it would do that regardless of
the city. (decided not to use that). Also was going to add a
"/tags:(x,y,z,w)" style supplement to be able to submit a set of
unordered tags but this also proved overkill. However when doing
faceted metadata search the order really isn't important and so order
in the url sholdn't be either I think.

This suggests to me that it would be useful to create a general url
windowing module that lets you specify (and validate urls to) an url
format in which certain segments of it may be structured differently.
By window I mean it lets you look at and define segments of urls. It
could pick up collisions between adjacent keywords too. Could also pad
missing virtual folder names (like setting All_Cities if not present).

I guess you'd define subs for each window spec.

The definition would see x.com/dir/[CITYSPEC]/[MAJORSPEC]]/[MINORSPEC]

It need not be complicated as the purpose is human readability. I know
Accept-Language is good REST but it is less intuitive and personally I
detest being forced to read a Japanese page for a website that has
perfectly good English on it.

It might be useful if you could define a certain format, like
YYYY-MMDD for a publication date, for a certain spec. Then it would be
easy to pick up on whether it is present or not and you could easily
handle "x.com/Jones/2008-0428" as well as "x.com/Fiction/Jones" and
even "x.com/Jones/EarlyWorks" (if you allow the date spec to include
EarlyWorks, defined as within 10 years of the first PubDate on
record).

Anyway the fr/en switch is a small subset of this functionality which
is otherwise very useful for helping users (and hopefully Google)
intuitively navigate orthogonal metadata (think Author, PubDate,
Topic) or data organized into hierarchies with crosslinks, like a
Yahoo style topic hierarchy. I suppose this is too long a post but it
would benefit all catalyst sites if created. I suppose UrlFu or the
like.

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

telebody at gmail

Apr 28, 2008, 8:42 AM

Post #25 of 28 (783 views)
Permalink

Re: Multi-language and REST [In reply to]

FWIW after all that such a module should allow keys stored in cookies
to supplement/overwrite the url. So instead of prepending lang code, I
could keep the same url but have a javascript language button set the
language.

/me shuts up now.

Matt R.

_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com