You have a multilingual application, and you want the URL of a page to be different for different languages, to account for SEO. The URL for the contact page for example should look like http://something.com/en/contact in english, and http://something.com/de/contact in german. This tutorial describes how to make it happen.
Note that currently selected language is always a part of the URL, and thus available to the application through $_GET. You don't have to use sessions variables to keep track of the language if you don't want to.
You would find having such a need in most Yii Projects. Your database needs a specific format to store date fields, while you may want to display it in different formats to the users on forms and other views.
To fix issues with display of special language characters once and for all
there's a solution: use Unicode UTF-8 everywhere. If everything is set up to use Unicode, you can use mostly every language in your application.
Yii core messages refer to static text strings in the core Yii framework code which are meant to be displayed to end-users (e.g. core exception messages, default validation error messages). Customization of these core messages is needed in two circumstances:
I needed British (dd/mm/yyyy) formatted dates throughout my application but found it very difficult to find examples of how to do this - until I found this excellent forum post http://www.yiiframework.com/forum/index.php?/topic/3649-dealing-with-i18n-date-formats/
In case of a multilingual application, one might consider it a reasonable approach to store the preferred language of the user in a session variable, and after that, every time a page is requested, to check this session variable and render the page in the indicated language.
This tutorial shows a Yii-way of doing this.
We implement an event handler for the onBeginRequest event; as the name of the event suggests, this event handler will be called at the beginning of each request, so its a good place to check whether a language is provided (via post, session or cookie) and set the application language accordingly.
We also implement a simple Language-Selector Widget, which can render the language options as ajax-links or as a drop-down list.
I wanted to keep all the I18N related translations in separate files, so that I would not need to modify the view files or the model files every time I need to update or fix the translations
of application's source language.
As you know, the CDetailView widget displays details of a single model. If no formatting is specified, boolean values that are stored in the database as 0 and 1, are represented in the detail view as 0 and 1. If formatted as boolean, they are represented as 'No' and 'Yes'. We want to add i18n support, so that Yes and No appear in the current language.