I just had a really cool idea to help with internationalisation when using AxKit... Basically you develop one site on one server but point different domain names at the same IP - so you might get www.fr.mysite.com, www.de.mysite.com etc etc.
Then you write a StyleChooser module for AxKit that picks the stylesheets based on the Host: header.
Of course you need to do all the other things you have to do in i18n like try your best to select based on Accept-Languages and so on. But this fits very nicely into AxKit's architecture.
It also solves a problem for me - what if companies want to re-sell your service, but change the look and feel of the "admin" site. You simply do the same as above, but implement a complete restyling rather than just i18n.
Re:or /fr /de ?
Matts on 2003-02-21T09:20:20
Robin Berjon has lots of experience writing i18n stuff with AxKit, though we should probably take this to the users list now.
Personally though I think it looks nicer to give different countries their own domain and do i18n that way. I don't like the whole subdirectory thing.Re:or /fr /de ?
darobin on 2003-02-21T11:31:16
I personally prefer domains, but that's mostly because I like the directory structure to reflect the organisation of content (language being an attribute or possibly a view, not a section).
What you still have left to do after using Matt's trick or something similar is images. Images that have text on them should be language specific, while others should be shared. You can use content negotiation for that (foo.png.fr, foo.png.de...) but that only works when the browser is set-up right, so you often have to go to modperl for those too (unless you're ready to have several separate image dirs).
One thing I've always wondered but never had a chance to test is whether setting Accept-language from modperl very early in the request will cause the mod_negociation to do the right thing farther down the pipe. I have to investigate that someday.
Re:or /fr /de ?
Matts on 2003-02-21T12:43:44
Images is handled by the selection of stylesheet.Re:or /fr /de ?
darobin on 2003-02-21T12:53:51
You'll have to excuse me but that is a bit cryptic
:) Re:or /fr /de ?
Matts on 2003-02-21T13:19:59
Sorry:)
I mean if you've got a stylesheet being chosen based on Host: your stylesheet can point to french or german or other images, and also point to shared ones.Re:or /fr /de ?
darobin on 2003-02-21T13:40:06
Of course, but the idea is to have a nice way to not have to worry too much about that during stylesheet creation and file management. IOW, it's much better if you can simply have
<img src='foo.png'/> in your stylesheet, and have Apache pick up foo.png.fr or foo.png.de automagically for you (as in conneg). It saves one from a lot of stupid mistakes:) Re:or /fr /de ?
Matts on 2003-02-21T17:12:23
Ah, well your AxKit plugin can do that for you. Just set $r->filename() and then return DECLINED.Re:or /fr /de ?
darobin on 2003-02-21T18:10:30
Yes, that's, definitely one option I was thinking about, I just thought it might be nicer if the plugin could $r->header('Accept-language', 'fr'), return DECLINED, and let mod_negociation deal with selecting the image (irrespective of order so that foo.png.fr, foo.fr.png, foo.png.fr.gz all work) and defaulting.
Re:or /fr /de ?
sbwoodside on 2003-02-21T18:14:38
OK, I understand that. I agree that the filesystem should be the content (I'm sticking to that to, until some unsolvable problem disabuses me in the future...)
It would be pretty sweet if axkit would pick the images automatically, specifically, if they're in fr.example.com, it would look for/img/foo.png.fr and serve it up as foo.png. Also, it would be nice, if there is no localized image, it would simply fall back on the non-localized image, so that you don't have to make localized versions of everything.
Would I store the localized versions of pages in the same directory as the normal page, or would there be a totally separate hierarchy for localized versions? Again, I think a separate hierarchy would be OK, especially if it would automatically fall back on the non-localized default version if it doesn't find a file ther (allowing incremental localization, and lots of code re-use by having non-localized stylesheets etc.)
