Internationalization
All aspects of the rXg captive portal web application are internationalized and capable of supporting localized presentations. This enables operators to deploy captive portals that vary in presentation based on browser language preference and/or manually selected language overrides.
Localization Selection
The rXg captive portal web application internationalization supports selection of localization in two different ways:
- Automatic determination of preferred localization through browser preference supplied via HTTP header
- Manual selection of desired localization via CGI parameter
Most operators will choose to use both localization selectors in parallel. The automatic selector is used to determine the initial localization preference and display a portal. The assumption is that the end-user will have selected a language preference in their browser or OS that is reasonable and meaningful. However, in some cases the OS and/or browser setting may be incorrect or insufficient to select an appropriate localization for display. Therefore most localized portals will also have links incorporated into the views them that enable manual localization override.
The key of the CGI parameter used to override the localization preference read from the browser is locale. The value of the locale key is the desired language abbreviation (e.g., en, fr, etc.). An example of a link to override the automatically selected localization is:
<a href="/portal/default/?locale=en">English</a>
Localization Implementation
The rXg captive portal web application internationalization features support implementation of localization in three different ways:
- String Translation with Gettext
- Localization conditionals within a view
- Selection of localized views Operators may choose to use any of the three available mechanisms individually or in any combination that is desired. ## String Translation with Gettext
The globalization support features of the rXg captive portal web application implement translation using the gettext application. Gettext allows the externalization of translation text while still maintaining the readability of the underlying views and partials. The source language is used in the views within the _() helper function, and external files map these strings to their translated counterparts.
For example, consider the following simple (untranslated) view (logout_success.erb):
<h2> Logout Successful </h2>
<p> You have successfully logged out. </p>
<p> Please come and visit us again. </p>
Implementing the string translation mechanism results in the following code for the view:
<h2> <%= _('Logout Successful') %> </h2>
<p> <%= _('You have successfully logged out.') %> </p>
<p> <%= _('Please come and visit us again.') %> </p>
The view code calls the _() function to look up a localized string in the appropriate place in the view. The set of available strings are stored in resource files in the locale/gettext directory of a custom portal.
An example of the source language (English) Gettext resource file (en.po) that corresponds to the string view shown above is shown below:
msgid "Logout Successful"
msgstr ""
msgid "You have successfully logged out."
msgstr ""
msgid "Please come and visit us again."
msgstr ""
An example of a French Gettext resource file (fr.po) that would work with the same view we have been considering is shown below:
msgid "Logout Successful"
msgstr "Dconnexion russie"
msgid "You have successfully logged out."
msgstr "Vous vous tes dconnect avec succs."
msgid "Please come and visit us again."
msgstr "S'il vous plat revenez nous rendre visite."
The default.pottemplate file may be copied into the portals gettext directory as_languagecode_.po (where languagecode represents the two-letter locale code for the language, e.g. fr or es) and edited/translated directly, or it may be provided to a third-party translation service, with the resulting .po files stored in the gettext directory of the custom portal.
For example, a new French locale translation file for the myportal Custom Portal can be started by running
mkdir -p /space/portals/myportal/gettext
cp /space/rxg/console/config/locales/gettext/default.pot /space/portals/myportal/gettext/fr.po
and then editing the fr.po file with the appropriate translations for the listed strings.
This enables the captive portal web application to use the appropriate strings for a given language preference. The strings in the source files are used when the captive portal web application renders the the view for a request from a web browser with an English language preference. The strings in the portal_directory/gettext/fr.po file are used when a request is fulfilled from a browser with a French language preference.
Inline Conditionals
Conditionals may be placed inline in a layout or a view to modify content based on language preference. For example, if a captive portal is localized for English and Spanish languages, then it would be appropriate to have an English override link when Spanish is being displayed and vice versa. The following code fragment exemplifies how this might be accomplished:
<% if I18n.locale == :en %>
<li class="menuparent"> <%= link_to 'Espaol',
{ :action => :index, :locale => :es },
{ :class => 'menuactive' } %></li>
<% else %>
<li class="menuparent"> <%= link_to 'English',
{ :action => :index, :locale => :en },
{ :class => 'menuactive' } %></li>
<% end %>
It is possible to use inline conditionals instead of string externalization to change the text being displayed. However the result is view code that is difficult to read. Thus, inline conditionals should be reserved for situations where small structural changes to the view are desired.
View Selection
The rXg captive portal web application supports view selection based on language preference. The operator may choose to have bothlogout_success.en.erb and logout_success.fr.erbfiles instead of a single logout_success.erb view file. Thus entirely different views may be presented to the end-user based on browser language preference.
