dannylewin;11041569 wrote:
I made a website multi-lingual using both mysql (for main bulk text) and include files for snippets, small segments of text and localized country settings. But its a little messy.
Definitely stick to one single source for texts. Preferably db.
dannylewin;11041569 wrote:
Also, there are bits of html which are part of the design in the DB which I don't like.
Keep your different stuffs separate. You will otherwise either end up copy pasting parts to remove html code and retrieve text only, send texts for translation, receive translated texts and having to brake those apart and copy paste pieces back in among html code 🙁
And if you don't do that and send entire mixes of html and texts, you will at the very best end up with confused translators. But you might actually end up with them translating things like <table>
dannylewin;11041569 wrote:
What's the best way of handling a site with multiple languages that's easy for others to administer?
This is pretty much the question to ask in order to answer all your other questions… At the very least an interface allowing someone to get all texts in whatever language they prefer, ability to specify input language for new translation. Side-by-side views for two specified languages for inspection later on. Everything obviously also needs to be searchable.
It would be even better if you can manage to also show context, as in show where the text is actually used. There are two problems that arise if you do not provide this functionality. First off, the translation may end up being incorrect. Secondly, there are sometimes spacing issues. Some languages tend to generally take up a lot more space than others, which can result in broken menus etc unless specific care is taken. One way of achieving this is by storing the surrounding html along with its text whenever you retrieve the text entry. If you cache the result, you will not need to retrieve a text entry more than once for a given placement. Another way is to simply store the url of your page or the url of the ajax request in case you use a one-page setup or sometimes create widgets this way. At least your translators may then be able to see the page in question and hopefully find their text entry without too much trouble.
Perhaps it would even be easier to instead crawl your rendered pages, break out the text entries, insert them into the db using some automated naming/placing convention. But doing it this way means you must achieve some way to create all pages that may be requested.
dannylewin;11041569 wrote:
I didn't want it to use the database too much which was why it only uses it for the main page text, heading, meta title, description ect.
I'd rather recommend you use only the db for this. You may however cache your pages once they have been rendered in a particular language.
dannylewin;11041569 wrote:
Should I created a table for each page layout type and have the fields for that particular layout??
This may be the easiest way to go about it. It may lead to having the same texts entered, and translated, multiple times for different pages though. But you should probably think smaller than "page". Some things are likely to exist on several different pages. Menu bar, search thingies etc.
dannylewin;11041569 wrote:
Its just the companies second website is going multi-lingual soon and id like to get it right and as good as possible before implementing it on the second site.
However you go about it, there will be work, head-scratching and problems to solve. So while I havn't used it myself, I'd definitely give a +1 for checking this out
