IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Re: Odds and ends
RE: Multi-lingual web content

Sounds like Todd's field of expertize

Yep. Here's the thing. You don't want to store whole html web pages as translatable elements. The reason is that people who do language translations don't know jack about html - so they invariably delete a closing tag here or there. Instead, you need to classify tags into two types: structural (table, paragraph, list) and inline: (bold, link, italics...). Structural tags are what your templates contain. Its your page layout (although you need a way to have locale specific layouts for the people who read right to left and top to bottom).

Then you put all the text in as large of blocks as possible into your database, inline markup and all. The reason you keep the inline markup is that it tends to move around. Example:

English: The red [link|http://www.apple.com|apple].

Spanish: La [link|http://www.apple.es|manzana] roja.

Notice that the link locations also change. So links want to get handled specially too - one more level of lookup needs to be kept to translate links (or not - depends).

Writing an intelligent html editor that can handle all this freaky stuff is hard. One more thing to keep in mind is that translations can usually be done on a sentence by sentence basis. Some phrases recurr often. For instance, suppose you are translating the website for the Gap. The Gap has trademarked the phrase "stone washed jeans". One additional tool is translation memory - a phrase database that stores translated stuff within the context of the current content.

A good translator's editor will tie into the translation memory database and actively try to assist the translator with known past translations. This helps provide decent consistency if you have a team of translators working on a big site. The translation memory database is shared and the editors are tied in "hot". Its more like groupware.

There's a bunch more issues wrt font rendering and character encoding conversion that needs to happen in the web server but suffice it to say that almost any other idea is a better one than trying to get into multi-lingual web content management.

FWIW, my former company, after hiring a total moron as VP Eng, and allowing him to eliminate my job after I already designed everything and built most of it, has finally fucked me by doing a 640 to one reverse stock split in their last round of funding. Basically diluting me from maybe getting my boat paid for to making it unlikely that I'll be able to buy a cheeseburger after any IPO.

I'd prefer they'd folded the company so I could just write off my loss.
New Err not the whole HTML
just the parts of it that the database will fill in, like the title part, the header information before the input box, etc. The ASP page or CGI program will parse out the HTML and fill in the blanks with the data from the database table.

"Oy! Seats taken mate!" - "Brilliant!" on BBC America
     Programming ideas I have had - (nking) - (7)
         Re: Programming ideas I have had - (admin)
         Odds and ends - (ChrisR) - (2)
             Re: Odds and ends - (tuberculosis) - (1)
                 Err not the whole HTML - (nking)
         Re: POS, Point Of Sale, that is. - (a6l6e6x) - (2)
             Ah, your no fun... :-) - (ChrisR) - (1)
                 My feeling is that Norm should pick something that: - (tonytib)

Can bitching and moaning atone?
75 ms