So I need to make a site available in different languages. Using PHP 5.x and MySQL 5.x. I believe I will be using gettext which seems fine for static text throughout the site but what about dynamic data that is stored in the db? Im referring to things like stories, events business listings etc. How do I get those to display in a different language? My initial thought was in the backend have them be able to enter multiple versions of a story, event or listing, one for each language they want to use on the site. But there could be thousands of entries times how many languages they want to show. Is there a better solution/idea that someone can point me to?
Also another issue I was thinking is currently the site allows you to search events/stories/listings, how would that work in different languages? Im assuming if someone selected the site to show in spanish they are going to use spanish words to search the site, but if the information in the db is in english I dont know that would work. Any suggestions on that?
If you want the stories to be correct in all languages, then you need them stored in all languages and provide the backend to do the translations or enter the stories on different languages as you initially thought.
If you don't like that, you might add the google translate element in your pages, to provide automatic (not correct) translation.
For the search question, I would only search for the keywords in the fields of the database in the same language as the user. If Joe is visiting your page in English, only look for the search terms in title_en, content_en, description_en fields of your database (or the ones with language='en' if you have one row per article and translation in the database, instead of one row per article (with all translations inside)). Obviously, this does only work if you put all the translations on the database.
The best solution I have seen described is this.
As i18n CMS sites as you describe are in a constant state of flux, with new articles being added, some of which have had translations, in some languages.
If an article in a chosen language has not yet been translated then show a default language (English?).
Then pick any ideas which appeal to your case:
a) If showing a default article in English also throw onto the page an input box and invite your audience to translate it for you.
b) If showing a default article in English also put on the page an offer to send the content to google translate as well as doing a) above
c) put a bounty on the translation and optionaly do a) and/or b) above.
Related
I'm currently creating a multi-lingual website, and I have different types of words that are being translated all across the website. However, whats the best practice when it comes to storing this in the database?
This is what I currently do:
I have the language Norwegian and English.
My database looks like this:
Whenever I add a new language it get added into the languages table like this:
At the same time a new table will be created with looking like this language_en. Using the value in language_val.
Later on I use URL routing to retrieve en, no or whatever language and fetch the website information from the correct table.
My question is, should I rather have only 1 table and use the language_id in this one? or is it perfectly fine to split up languages into multiple tables?
Each language table would look just like this:
With Silverlight (and later with PHP) I've done this by putting the language's in the same table, this worked fine and was user friendly (easy to edit). Only when retrieving data you should off course only select the language you need.
We're busy with a CakePHP project which needs to support multi languages. But there is one problem.... There are pages which are NOT supported for other languages. So there are Spanish pages which need to be hidden for the Italian version of the website. What is the better solution for this in CakePHP?
We can switch databases as soon as you switch languages, but the problem is that we will miss important data as users and such if we'll do that. And it may be overload to search a database with Spanish, Italian, German, English, Netherlands and Swedish posts, only for the Spanish posts. Or maybe it's not a problem if we index the language column... but I don't know.
So does anyone knows the better solution?
Definitely NOT multiple databases IMO. Instead, try to just keep your record separate from it's contents.
Example:
articles table contains non-language-specific data like article id, created date, modified date...etc
article_contents contains language-specific data like title, subtitle, content, authors...etc as well as an article_id field and a language field.
Then, if you're on the Italian site, you can pull with an INNER JOIN to the contents where it matches the language you want.
Or there are many ways depending on your setup on how you should pull data, but hopefully the idea for separation of generic data vs language-specific data helps.
instead of
echo 'Localization';
do
echo __('Localization');
http://book.cakephp.org/2.0/en/core-libraries/internationalization-and-localization.html
I am currently making a web page with dynamic content from a database (a restaurant menu) storing item names, prices, yada yada. The restaurant usually caters to English and Japanese. I have stored the titles of the items in the database as English and Japanese, however when it comes to the type of the item, for example, Type: Drink, Type of Drink: Coffee I can obviously store the type of item alongside the item in the database, but it hardly seems worth it to store it twice as two different languages in the the database which would also make the form to add a new item a pain.
What is the best way to go about translating those little tiny pieces of information, like "Coffee", "Wine", "Click Here", "Menus", and using them on the page?
You can use gettext extension for translation static or predefined info on web page.
See manual http://php.net/manual/en/book.gettext.php
Example http://mel.melaxis.com/devblog/2005/08/06/localizing-php-web-sites-using-gettext/
I would store it in both languages, it makes the most sense to me. I don't see why you would go and do a request to your translation system each time you want to show any page in your menu.
If you are using an automatic translation system that you really trust, one thing that you could do is use it when adding a new item to make a suggestion. So, after the user enters the word in English on the form, automatically attempt to translate that into Japanese and put it in the Japanese field. If the user is satisfied with the translation, that's it for that task, otherwise he/she inputs with a better one.
if you are using any phph5 based framework , major framework have localization support like zend has Zend_Locale
if you want your own translation dictionary , keep key value pair data in database table and memcached between application and DB , so static data will be cached for particular expiry time and data base load will be get decreased and fast retrieval of data
Not sure if stackoverflow is the most appropriate place for this question.
I am currently building a web application that will manage content, ecommerce and allow users to participate.
I am using php's intl extension to deal with different number formats and so on. gettext will be used to provide translations of the actual text in the application.
This question isn't really a technical one, but more as to how the user sets the language/version of the web app.
I have came up with a possible scenarios:
(Country regions) User selects his country and this determines his language. If the language for his country is not avaliable, default to default language.
(Language) User selects his own language, and he selects his own country/time zone settings. That means we can have users in say the United states reading content in Japanese.
With the first option, obviously it is quite fool-proof. The user claims he is from canada, so we display the content in english (en_ca) or french (fr_ca if avaliable).
However, not every web site built on top of the application will be big enough to warrant translations based on locale (i.e. canadian french (fr_ca) vs french french (fr_fr).
Some site would be quite small, so it doesn't matter where the user comes from, he should be able to select either French or English when browsing the site. However, this leads to another issue. If the user selects the content to be shown in french, how do we format things like numbers and currencies? We cannot directly infer his locale from the language he has chosen.
I have looked around the web at some "big" websites to look at how they do things.
Amazon - (Country Regions) Different sites for different countries, i.e. Amazon japan is only avaliable in japanese.
Microsoft - (Country Regions) Some countries have multiple languages. (fr_ca) vs (en_ca).
Engadget.com - (Language) English, Japanese, Chinese (both simplified and traditional).
FaceBook - (Language), but offers different versions of languages (fr_ca and fr_fr)
So I guess the question is, should I force all users of the web application to build their content around the countries/regions or languages? Or should I allow both scenarios?
Cheers :)
As a professional localizer, I reccomend "language" if there is no difference in content.
The reason why Amazon or MS ask for country is that the content is different for each territory. For stuff that is not available, say in Japan, why would they want to translate it to Japanese? Plus it's misleading to the Japanese reader, even if they are on the US site.
On the flip-side, if you offer Country as the selection, then users may expect to see different content based on the coutry they choose, and that might be misleading.
These days a lot of people are mutli-lingual so if the content is the same, defaulting by location then offering the language selection on top is more user-friendly.
I hope my thoughts might help. This is a tough question and depends on many factors - there is no 'right' answer. :)
We did something similar to this in our web app. We essentially just used the currency format of the "home" country for the language. So, if they choose French, they get France's formatting. German, Germany's formatting, etc. It won't always be the correct one but for our app we haven't had any complaints yet, so I assume that works the best if your users aren't too picky. We have a decently small userbase, however (<= 1000 visitors per instance of our app), so you may want to take this advice with a grain of salt ;)
Trying to work this out, but I don't know what's the best practice for this kind of things.
I'm working on a website using 3 languages: English, French & Dutch. There are categories on the website and the category names are different for the 3 languages.
For example:
Stars -> English
Sterren -> Dutch
Stars -> French
So I was thinking about adding them to the database. It's also easier for me to add more categories later if needed.
Now I'm facing the problem how to do this. My solution is:
**Cat_lang (category languages)**
cat_lang_id
language
**Categories**
categories_id
cat_lang_id
cat_title
Using cat_lang_id I can link both tables to get the language I need.
Is this the best solution for this problem?
Thanks in advance.
So that you can expand your website more easily in the future, I dont recommend having a cat_lang table. Stick with a languages table that contains language_id and language_name, and have your categories table point to it. Doing it that way allows you to have other entity types in your database (e.g. articles) that also contain multiple languages.
This is a flexible and reasonable solution. You see the same type of design in large scale ERP systems that have to handle dozens of languages and the possibility of more being added at any time.
If I were doing a website in multiple languages, I would use Zend_Translate to do the translations. Basically, you create a Zend_Translate object which reads in data files. Then you make calls on that object to translate() giving it the english version and it will give the translation in the correct language. Zend_Translate will scan your source and find all references to requested translations which will make files that can be translated by hand.
You are going to have much more than just the category names to translate, so I would recommend an approach like this where you just read in the translate file.
If you don't plan for a massive scale website and that you don't plan to increase to 100 languages, you can do a simpler and 'less nice' solution that is to have only 1 table of categories, where you hard code the language code in the category_name, for instance:
**Categories**
categories_id
cat_title_fr
cat_title_en
cat_title_de
Then in your code you set a $language_code variable at the beginning of each page using an include, you can even analyze the domain name in the $_SERVER variables to asign the correct language an by default choose the one you like (if you leave the variable empty your queries will return no text).
and you generate your queries like this:
mysql_query("SELECT cat_title_".$lang." FROM categories;");
Yeah it is dirty because you hard code the language in your DB structure, but if you have the exact same categories in each language with just a translation of the name, it is simple to implement.
Besides to add a language you just need to add a field in your table with the new translation, for instance spanish would be
cat_title_es