week 10 bug fix submission (SF PDK version): Bug 1892, Bug 1897, Bug 1319. Also 3 or 4 documents were found to contain code blocks with SFL, which has been fixed. Partial fix for broken links, links to Forum Nokia, and the 'Symbian platform' terminology issues.
<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License
"Eclipse Public License v1.0" which accompanies this distribution,
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
Nokia Corporation - initial contribution.
Contributors:
-->
<!DOCTYPE concept
PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-F35C5336-907C-5B2A-92C6-F8883D49996E" xml:lang="en"><title>How
to localise resources</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<section><title>Overview</title> <p>Symbian developers can localise a C++
application by simply changing the resource file text associated with each
menu item, task bar or other control. Since changes to the text do not change
the symbol information in the generated header file, it is not necessary to
recompile the application to use the new file. Consequently, a resource file
may be generated for each language supported, and the actual resource used
is determined by the end-user at installation time. </p> <p>The examples quoted
in this page are taken from the code example <filepath>Examples\ToolsAndUtilities\Localise</filepath>,
which provides the Hello World application, localised for English and German. </p> </section>
<section><title>Localisable strings</title> <p>Localisable strings should
not be defined within a resource file, but in separate files with the extension <filepath>.rls</filepath>.
An <filepath>.rls</filepath> file defines symbolic identifiers for strings,
to which the resource file refers when it needs the associated string. </p> <p>An
example from an <filepath>.rls</filepath> file is shown below: </p> <codeblock id="GUID-FA54B424-D6C1-5A80-821D-3B25A720873D" xml:space="preserve">// Strings localised for UK
rls_string STRING_r_example_first_menu_name "Hello"
rls_string STRING_r_example_item0 "Item 0"</codeblock> <p>The keyword <codeph>rls_string</codeph> appears
before each string definition, followed by a symbolic identifier, and then
the string itself in quotes. To localise the file for German, the same identifiers
would be used, but the strings would be translated, i.e. </p> <codeblock id="GUID-722A8D45-5747-5FE8-A3C6-FE9AD2C43542" xml:space="preserve">// Strings localised for German
rls_string STRING_r_example_first_menu_name "Hallo"
rls_string STRING_r_example_item0 "Eintrag 0"</codeblock> <p>The resource
file itself would be the same, whatever the locale, as it would only refer
to strings through their symbolic names, e.g. </p> <codeblock id="GUID-D427E092-1BA9-56A8-B449-DFDA182107AE" xml:space="preserve">MENU_TITLE
{
menu_pane=r_example_first_menu;
txt=STRING_r_example_first_menu_name;
}</codeblock> <p>defines a menu title resource, with a title string defined
by <codeph>STRING_r_example_first_menu_name</codeph> (i.e. "Hello" in UK,
"Hallo" in German). </p> </section>
<section><title>Building localised resource files</title> <p>You can define
in a project definition (<filepath>.mmp</filepath>) file the locales that
the project supports. Given appropriate resource source and <filepath>.rls</filepath> files,
the build process then builds a separate compiled resource file for each supported
locale. </p> <p>The process in detail can be broken into three steps: </p> <ul>
<li id="GUID-89FC1834-F661-5341-A03C-9F068CAC0655"><p>determine on a symbolic
identifier for every supported locale </p> </li>
<li id="GUID-CEBA3187-2758-5D17-9CE1-032D037BE9F9"><p>specify in the project
definition file the supported locales </p> </li>
<li id="GUID-48C74787-5367-5EE9-ACF9-8A67E87B3CA3"><p> <codeph>#include</codeph> the <filepath>.rls</filepath> files
for the supported locales in the resource source file </p> </li>
</ul> <p>These are discussed further below. </p> <p><b>Locale identifiers </b> </p> <p>You
should decide on a symbolic identifier for every supported language. The symbol
should be of the form: </p> <p> <codeph>LANGUAGE_</codeph> <varname>language-code</varname> </p> <p>where <codeph>language-code</codeph> should
be two characters long, but otherwise can be anything you like, as long as
each language in the resource file has a unique symbol. </p> <p>You are recommended
to use a standard two-digit number as defined by Symbian in an enumeration <codeph>TLanguage</codeph> in <filepath>e32std.h</filepath>,
which gives numeric values to the languages. For example, the value <codeph>ELangGerman</codeph> (German)
in <codeph>TLanguage</codeph> has the value 3, so you could use <codeph>LANGUAGE_03</codeph> as
the symbol for German. </p> <p>Alternatively, you can use logical letters
for each language: e.g. US English might have the symbol <codeph>LANGUAGE_US</codeph>,
while French might have the symbol <codeph>LANGUAGE_FR</codeph>. </p> <p><b>Project
definition files </b> </p> <p>For projects with localised resources, you must
use the <codeph>lang</codeph> statement in the <filepath>.mmp</filepath> file
to set the languages codes used. So, for the above example, in which the language
codes used are for German (03) and UK English (01), the <codeph>lang</codeph> statement
should read: </p> <codeblock id="GUID-BE1AE938-89E7-5E9C-B71D-81F16A64748C" xml:space="preserve">lang 01 03</codeblock> <p>When
the project is built, each resource file specified in the project file will
be compiled multiple times, once for each language-code specified. The language
codes are used to complete the extension of the built resource files: for
our example, two files would be built: <varname>project-name</varname> <filepath>.r01</filepath> and <varname>project-name</varname> <filepath>.r03</filepath>. </p> <p><b>Resource source files </b> </p> <p>The symbols can then used,
with conditional compilation statements, to specify which string definitions
should be compiled for each language. In the example code fragment below,
the file <filepath>01-strings.rls</filepath> is assumed to have the strings
localised for UK English, and the file <filepath>03-strings.rls</filepath> the
strings localised for German. </p> <codeblock id="GUID-51F46C07-27F9-5A36-A2C2-374A61C5EBF7" xml:space="preserve">// Conditional compile, depending on locale
#ifdef LANGUAGE_01 // if language code is for UK
#include "01-strings.rls"
#elif defined LANGUAGE_03 // if language code is for German
#include "03-strings.rls"
#endif
// end conditional compile
</codeblock> <ul>
<li id="GUID-95464F59-9F66-5984-8B31-1A77D91EC033"><p>when built with the
code 01, the UK English strings in <filepath>01-strings.rls</filepath> are
compiled into the resource file </p> </li>
<li id="GUID-48DE7451-D93E-51F0-8B43-2EA94A68E800"><p>when built with the
code 03, the German strings in <filepath>03-strings.rls</filepath> are compiled
into the resource file </p> </li>
</ul> </section>
<section><title>How programs load resource files </title> <p>The Uikon application
framework attempts to load the project's resource file when the application
starts up. If the resource file has the extension <filepath>.rsc</filepath>,
then this is loaded. Alternatively, the framework attempts to load the correct
resource file by comparing the system locale setting with the available resource
files: for example, in a German locale, the resource file with extension <filepath>.r03</filepath> would
be loaded. Resource files that are explicitly loaded by programs, rather than
by the framework, can use the same stategy, by calling <codeph>BalfUtils::NearestLanguageFile()</codeph> to
find a resource file with the correct language extension. </p> <p>More typically
than installing all the resource files for all the available locales, you
would only want to select a single resource file for installation, based on
the system locale or user preference. The Symbian platform Installation System
enables this, as described in <xref href="GUID-5D508751-C824-48E4-A6E3-0C5EA05DEC99.dita">PKG
file format to support multilingual application installation</xref>. </p> </section>
</conbody></concept>