Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It would seem more standard to use subdirectories instead of subdomains, judgeing from what's out there right now. Anyway, something to make i18n would be sweet, right now the best i18n ideas I've seen are in Cocoa (which makes it dirt easy).
    • 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

      --

      -- Robin Berjon [berjon.com]

      • by sbwoodside (3935) on 2003.02.21 13:14 (#17372)
        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.)