Two things come to my mind:
1. German sentences are usually longer than english. This could disturb table design.
2. German Umlauts (ä,ö,ü,Ä,Ö,Ü) are ordered near their normal vowels (a,o,u), which is not so in ASCII. I'm not sure mysql can cope with that. | [reply] |
The way I usually do categories of products on a website is to create a "synthetic" sort order- I allow the administrator to put categories in whatever order they want. I find this is far more flexible than relying on alphapbetical sorts.
I guess I'll need to figure this out down to the product level. She isn't going to list a whole lot of items, so I may put it a "synthetic" sort field for products too.
| [reply] |
HTML::Template for HTML, using the correct language template for a session.
Be sure to checkout Class::Phrasebook for a different way to handle this.
| [reply] |
A %ENV variable I use (with caution) when it comes to languages is $ENV{HTTP_ACCEPT_LANGUAGE}. It basically contains the language(s) you set in your browser. Different browsers send different language strings (NS sends uppercase, IE sends lowercase, etc). I'm pretty sure Google uses that var, and 'some billion dollar software company from redmond' has been known to abuse it too.
As for mom & dad: those books with animals on em don't mean I'm into sick stuff. It's not like I have Python books or anything.
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur. | [reply]
[d/l]
[select] |
My advice is not related to perl, but rather to database design:
Usually you have a lot of codes which are just abreviations, so you have tables with "code" "description", and you may use "code" where is not enough space for full description. In multi-language design, you want to avoid that, because code in one language might not mean anything (or worse, is common-sence widely-used abreviation for something else) in another language.
In example, we were developing loan servicing system, and used 2 and 3-letter codes for different statuses, i.e. "BK" was "loan is in bankruptcy". And sure we were checking for hardcoded status in our code. When faced with need to port this to italian, we could not. Database was able to display language dependent fields and labels, but not codes. We had to train users and added feature to display all current statuses with relevant description. Which is not bad even for native englich users;)
Every string what ever you might to display on user-friendly screen needs to have ID, code (short abreviation meaningfull in user language) and description. In your programs you'll use ID instead of code. In my case mentioned earlier, we might want to use 'bk' as ID, and "BK" as english code for bankruptcy.
And back to perl, you can create functions using global $user_language returning proper code and description for each ID, so implementation details will be hidded to your scripts.
HTH
pmas
To make errors is human. But to make million errors per second, you need a computer. | [reply] |