My website needs to be able to support multiple languages for multiple countries. For example, the US might have English and Spanish, while the UK might only have English. If two countries use the same language, it DOES NOT mean the content is the same.
For this reason, I decided to use the internationalization module (i18n) and I created language codes as follows:
gb-en - UK English
us-en - US English
us-es - US Spanish
I set this up with no issues, but my problem comes in with creating all the default content. For each content type, I want to:
Set the content types default language as "English"
Create translated versions of each content type for each language
I know this will mean that the Spanish content would still be in English, but it's the first step towards translating it.
What is the easiest way to create all these "default" content pages?
You could create a module implementing hook_node_insert(). This module would intercept the creation of a new node (stored with the default language) and create as many copies as needed. Each of these copies should have a different value in the field language. These copies colud be easily stored in the dabase using node_save() function.
Related
I create a taxonomy called colors.
Each of my term are translatable, in french and english.
I create a content type called product where I can associate a taxonomy color. Note that my product content type is multilingual aswell
My admin default language is french.
When I create a product,the color taxonomy is only showing in french which is my admin default language. In my mind, it's supose to be displayed within the language set in the node.
It's a problem right now because, english node is associated to french taxonomy.
Anybody know how can I resolve this issue.
Thanks a lot.
It depends on how your taxonomy was set up.
There are three different modes, beside from no-multilingual:
Localize. Terms are common for all languages, but their name and description may be localized.
Translate. Different terms will be allowed for each language and they can be translated.
Fixed Language. Terms will have a global language and they will only show up for pages in that language.
I guess colors are common for all languages, so I would recommend using the first option.
You can then translate the colors via config > translate interface.
When you chose the "localize" option you don't have duplicate colors showing up on node forms.
Update
If the terms are common for all languages but you want to add more fields to the terms, you could use localize and in addition use the entity translation module.
Entity translation allows you to translate the different fields for each term.
There are two drawbacks though:
On top of the entity translation you have to translate the terms via translate interface or else the terms will not be translated on the node-edit-forms.
You have to alter the aliases for the Terms yourself via /admin/config/search/path so the terms have different path aliases for different languages
This is of course not a good solution for user-generated terms but works if the terms are moderated.
If I want to translate the role to other language, how do I do it?
I can change that to other language as the default but I would like to use English so I don't have to deal with UTF8 issue in my code with Asian charactors.
if(in_array("administer nodes", $user->roles))
I have tried to find it from translation module but this seems not translatable as other text in Drupal.
So I'm assuming you've already tried using the t() or st() functions?
If that's so, you may need to try a client-side AJAX translation solution. One way you might do this is to create a vocabulary of terms (corresponding to the English role names), and have the Asian character translation as a secondary field. Then use views to create a view of this vocabulary, and create a lightweight module that:
1) loads a Drupal AJAX script on every page (or every page where role names might be utilized)
2) the script looks for a list of specified containers by id that you know will contain role names
3) searches the view you created for the English pattern, and replaces it in the container with any positive matches
Drupal API's example AJAX module
You could then expand the module/AJAX script to solve other similar translate fails on your site.
I am developing an application in cakephp 2.3.4, Which is multi-language.
Admin can add any number of new languages.
My question is, When admin decides to add a new language, how resulting locale name should be defined.
Can a locale name be any arbitrary name, given by admin or it should be a dropdown containg all languages code according to language.
Unfortunately, your question is a bit 'vague', i.e., will administrators be able to add GNU-locale files (*.po), or are you talking about adding translations inside the database.
In any case, CakePHP uses locales according to the ISO 639-3 standard see here and here for more information. A complete list of those locales can be found inside the I10n class.
Since you probably also want to switch the locale of PHP itself when switching locales, so that, for example, date, money and time-formats will follow the right format for the locale, it's best to stick with those locales and not 'invent' your own locales.
See setlocale(). Be aware though, that PHP may use slightly different locale-codes than CakePHP uses. And it will depend on what locales are installed on your server.
To get a list of locales installed on your server, use locale -a on the command line. See this page for more information: https://wiki.archlinux.org/index.php/Locale
Which techniques to use for localization
A quick summary of techniques to use;
Short messages (interface/UI)
In general, locale files are used for short pieces of text. Locale-files are therefore mostly used for fixed strings,
for example, strings that are used in the interface (like 'are you sure you want to delete this file?' => 'weet u zeker dat u dit bestand wilt verwijderen?).
Longer (fixed) text
For longer pieces of text in your application, that are not part of the 'content' (not the blog-post, but for example a fixed page with a disclaimer),
it's best to use separate views for translated content, for example;
app/Views/MyController/disclaimer_eng.ctp
app/Views/MyController/disclaimer_deu.ctp
app/Views/MyController/disclaimer_fre.ctp
Content
For the content of your website (the part of your website that is managed by the 'user' of the website),
put translations inside the database. This data may be updated frequently and all translations should be updated as well.
How to implement this, is really up to you and depends on your situation. CakePHP offers a Translate behavior that you can use (http://book.cakephp.org/2.0/en/core-libraries/behaviors/translate.html), but in most of my situations that behavior didn't really fit our needs (IMO it is not very efficient, because it stores translations per-field, per-model).
I was searched and read many websites but can't find how to set up drupal multi language website.
I want to use 2 languages in a site.
These 2 languages have different content. (not content translation).
I had enabled Locale module, enabled multilingual support in each content type
but when i was added content in 2 languages
the front page list all of those articles without filter the site's language.
how to setup drupal 7 to list articles with filtered language.
eg:
http://example.com/en <- this url should list all english article.
http://example.com/fr <- this url should list all france article.
I have to install i18n or Internationalization module from Drupal contributed modules and enabled these option.
Multilingual select
Internationalization
** This module require Variable module.
Since the content is different, one way to achieve this is by creating two different content types. Assign an alias pattern to each content type like en/[node:title] and fr/[node:title]. You can then display each or both content types on any page; it could be a taxonomy page with alias en or fr. If you choose this method you won't need locale. This one is not intended for translated sites where each content has a matching translated content.
If you also want to expand some special words which have not include in language lib, you can try following code:
$zh = variable_get('locale_custom_strings_zh-hans');//zh-hans is your language key.
$zh["More news"] = '更多信息'; // KEY/VALUE
variable_set('locale_custom_strings_zh-hans',$zh); // set it back.
A friend of mine is now building a web application with J2EE and Struts, and it's going to be prepared to display pages in several languages.
I was told that the best way to support a multi-language site is to use a properties file where you store all the strings of your pages, something like:
welcome.english = "Welcome!"
welcome.spanish = "¡Bienvenido!"
...
This solution is ok, but what happens if your site displays news or something like that (a blog)? I mean, content that is not static, that is updated often... The people that keep the site have to write every new entry in each supported language, and store each version of the entry in the database. The application loads only the entries in the user's chosen language.
How do you design the database to support this kind of implementation?
Thanks.
Warning: I'm not a java hacker, so YMMV but...
The problem with using a list of "properties" is that you need a lot of discipline. Every time you add a string that should be output to the user you will need to open your properties file, look to see if that string (or something roughly equivalent to it) is already in the file, and then go and add the new property if it isn't. On top of this, you'd have to hope the properties file was fairly human readable / editable if you wanted to give it to an external translation team to deal with.
The database based approach is useful for all your database based content. Ideally you want to make it easy to tie pieces of content together with their translations. It only really falls down for all the places you may want to output something that isn't out of a database (error messages etc.).
One fairly old technology which we find still works really well, is to use gettext. Gettext or some variant seems to be available for most languages and platforms. The basic premise is that you wrap your output in a special function call like so:
echo _("Please do not press this button again");
Then running the gettext tools over your source code will extract all the instances wrapped like that into a "po" file. This will contain entries such as:
#: myfolder/my.source:239
msgid "Please do not press this button again"
msgstr ""
And you can add your translation to the appropriate place:
#: myfolder/my.source:239
msgid "Please do not press this button again"
msgstr "s’il vous plaît ne pas appuyer sur le bouton ci-dessous à nouveau"
Subsequent runs of the gettext tools simply update your po files. You don't even need to extract the po file from your source. If you know you may want to translate your site down the line, then you can just use the format shown above (the underscored function) with all your output. If you don't provide a po file it will just return whatever you put in the quotes. gettext is designed to work with locales so the users locale is used to retrieve the appropriate po file. This makes it really easy to add new translations.
Gettext Pros
Doesn't get in your way while coding
Very easy to add translations
PO files can be compiled down for speed
There are libraries available for most languages / platforms
There are good cross platform tools for dealing with translations. It is actually possible to get your translation team set up with a tool such as poEdit to make it very easy for them to manage translation projects
Gettext Cons
Solves your site "furniture" needs, but you would usually still want a database based approach for your database driven content
For more info on gettext see this wikipedia page
They way I have designed the database before is to have an News-table containing basic info like NewsID (int), NewsPubDate (datetime), NewsAuthor (varchar/int) and then have a linked table NewsText that has these columns: NewsID(int), NewsText(text), NewsLanguageID(int). And at last you have a Language-table that has LanguageID(int) and LanguageName(varchar).
Then, when you want to show your users the news-page you do:
SELECT NewsText FROM News INNER JOIN NewsText ON News.NewsID = NewsText.NewsID
WHERE NewsText.NewsLanguageID = <<Session["UserLanguageID"]>>
That Session-bit is a local variable where you store the users language when they log in or enters the site for the first time.
Java web applications support internationalization using the java standard tag library.
You've really got 2 problems. Static content and dynamic content.
for static content you can use jstl. It uses java ResourceBundles to accomplish this. I managed to get a Databased backed bundle working with the help of this site.
The second problem is dynamic content.
To solve this problem you'll need to store the data so that you can retrieve different translations based on the user's Locale. (Locale includes Country and Language).
It's not trivial, but it is something you can do with a little planning up front.
#Auron
thats what we apply it to. Our apps are all PHP, but gettext has a long heritage.
Looks like there is a good Java implementation
Tag libraries are fine if you're using JSP, but you can also achieve I18N using a template-based technology such as FreeMarker.