dhis2-devs team mailing list archive

[noreply@xxxxxxxxxxxxx]

------------------------------------------------------------
revno: 734
committer: Jason P. Pickering <jason.p.pickering@xxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Wed 2013-05-08 10:43:55 +0200
message:
  (Implementation guide) Some more information on localization.
modified:
  src/docbkx/en/dhis2_localization_guide.xml
  src/docbkx/en/dhis2_user_man_getting_started.xml


--
lp:~dhis2-documenters/dhis2/dhis2-docbook-docs
https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs

Your team DHIS 2 developers is subscribed to branch lp:~dhis2-documenters/dhis2/dhis2-docbook-docs.
To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs/+edit-subscription

=== modified file 'src/docbkx/en/dhis2_localization_guide.xml'
--- src/docbkx/en/dhis2_localization_guide.xml	2012-02-18 07:50:49 +0000
+++ src/docbkx/en/dhis2_localization_guide.xml	2013-05-08 08:43:55 +0000
@@ -65,12 +65,22 @@
     </orderedlist>
   </section>
   <section>
-    <title>Things to keep in mind.</title>
-    <simplelist>
-      <member>There are a number of strings such as &quot;yyyy-MM-dd&quot; which are used for date/time formatting in the application. In general, these should not be altered, but there can be situations when they need to be localized. Consult this <ulink url="http://docs.oracle.com/javase/tutorial/i18n/format/simpleDateFormat.html";>site</ulink> for more information</member>
-      <member>It is not necessary to translate a string from the orginal language (English) if the translated string is the same. You can simply leave it blank. By default, DHIS2 will use English values for all strings which have not been translated. </member>
-      <member>All translated strings must be entered in UTF-8 format. If you are using the translation portal, be sure your browser settings are set to UTF-8 when translating. </member>
-      <member>Some special variables (e.g. {0} ) used curly brackets. This denotes a variable which will be replaced by a number or other value by the application. You must place this variable notation in the correct position. </member>
-    </simplelist>
+    <title>Important localization concepts</title>
+    <important>
+      <itemizedlist>
+        <listitem>
+          <para>There are a number of key/value pairs such as &quot;format.FinancialApril.startDate=dd MMM yyyy &apos;to &apos;&quot; which are used for date/time formatting in the application. Part of the value should not be translated because it is actually a Java date formatting template. It this example it is  &quot;dd MMM yyyy&quot;. Consult this <ulink url="http://docs.oracle.com/javase/tutorial/i18n/format/simpleDateFormat.html";>site</ulink> for more information on the Java date formatting syntax. The part of the value which can be translated would be &quot;to&quot;, for instance to &quot;a&quot; in Spanish. If these data format template strings are translated, it may result in errors in the application. </para>
+        </listitem>
+        <listitem>
+          <para>It is not necessary to translate a string from the original language (English) if the translated string is the same. You can simply leave it blank. By default, DHIS2 will use English values for all strings which have not been translated. </para>
+        </listitem>
+        <listitem>
+          <para>All translated strings must be stored in escaped UTF-8 format. If you are using the translation portal, be sure your browser settings are set to UTF-8 when translating. If you are using a text editor or other tool such as an IDE, you may need to convert the UTF-8 characters to escaped syntax, using the Java &quot;native2ascii&quot; utility. </para>
+        </listitem>
+        <listitem>
+          <para>Some special variables (e.g. {0} ) used curly brackets. This denotes a variable which will be replaced by a number or other value by the application. You must place this variable notation in the correct position. </para>
+        </listitem>
+      </itemizedlist>
+    </important>
   </section>
 </chapter>

=== modified file 'src/docbkx/en/dhis2_user_man_getting_started.xml'
--- src/docbkx/en/dhis2_user_man_getting_started.xml	2013-04-21 16:08:35 +0000
+++ src/docbkx/en/dhis2_user_man_getting_started.xml	2013-05-08 08:43:55 +0000
@@ -237,7 +237,10 @@
     <para>8. Design charts and customise the dashboard</para>
     <section>
       <title>The organisational hierarchy</title>
-      <para>The organisational hierarchy defines the organisation using the DHIS 2, the health facilities, administrative areas and other geographical areas used in data collection and data analysis.  This dimension to the data is defined as a hierarchy with one root unit (e.g. Ministry of Health) and any number of levels and nodes below. Each node in this hierarchy is called an organisational unit in DHIS 2. The design of this hierarchy will determine the  geographical units of analysis available to the users  as data is collected and aggregated in this structure. There can only be one organisational hierarchy at the same time so its structure needs careful consideration. Additional  hierarchies (e.g. parallel administrative boundaries to the health care sector) can be modelled using organisational groups and group sets, but the organisational hierarchy is the main vehicle for data aggregation on the geographical dimension. Typically national organisational hierarchies in public health have 4-6 levels, but any number of levels is supported. The hierarchy is built up of parent-child relations, e.g. a Country or MoH unit (the root) might have e.g. 8 parent units (provinces), and each province again ( at  level 2) might have 10-15  districts as their children. Normally the health facilities will be located at the lowest level, but they can also be located at higher levels, e.g. national or provincial hospitals, so skewed organisational trees are supported (e.g. a leaf node can be positioned at level 2 while most other leaf nodes are at level 5). Typically there is a geographical hierarchy defined by the health system. e.g. where the administrative offices are located (e.g. MoH, province, district), but often there are other administrative boundaries in the country that might or might not be added, depending on how its boundaries will improve data analysis.   When designing the hierarchy the number of children for any organisational unit may indicate the usefulness of the structure, e.g. having one or more  1-1 relationships between two levels is not very useful as the values will be the same for the child and the parent level. On the other extreme a very high number of children in the middle of the hierarchy (e.g. 50 districts in a province) might call for an extra level to be added in between  to increase the usefulness of data analysis. The lowest level, the health facilities will often have a large number of children (10-60), but for other levels higher up in the hierarchy approx. 5-20 children is recommended. To few or too many children might indicate that a level should be removed or added. Note that it is quite easy to make changes to the upper levels of the hierarchy at a later stage, the only problem is changing organisational units that collect data (the leaf nodes), e.g.  splitting or merging health facilities. Aggregation up the hierarchy is done based on the current hierarchy at any time and will always reflect the most recent changes to the organisational structure. Refer to the chapter on Organisation Units to learn how to create organisational units and to build up the hierarchy.</para>
+      <para>The organisational hierarchy defines the organisation using the DHIS 2, the health facilities, administrative areas and other geographical areas used in data collection and data analysis.  This dimension to the data is defined as a hierarchy with one root unit (e.g. Ministry of Health) and any number of levels and nodes below. Each node in this hierarchy is called an organisational unit in DHIS 2.</para>
+      <para> The design of this hierarchy will determine the  geographical units of analysis available to the users  as data is collected and aggregated in this structure. There can only be one organisational hierarchy at the same time so its structure needs careful consideration. Additional  hierarchies (e.g. parallel administrative groupings such as &quot;Facility ownership&quot;) can be modelled using organisational groups and group sets, however the organisational hierarchy is the main vehicle for data aggregation on the geographical dimension. Typically national organisational hierarchies in public health have 4-6 levels, but any number of levels is supported. The hierarchy is built up of parent-child relations, e.g. a Country or MoH unit (the root) might have e.g. 8 parent units (provinces), and each province again ( at  level 2) might have 10-15  districts as their children. Normally the health facilities will be located at the lowest level, but they can also be located at higher levels, e.g. national or provincial hospitals, so skewed organisational trees are supported (e.g. a leaf node can be positioned at level 2 while most other leaf nodes are at level 5). </para>
+      <para>Typically there is a geographical hierarchy defined by the health system. e.g. where the administrative offices are located (e.g. MoH, province, district), but often there are other administrative boundaries in the country that might or might not be added, depending on how its boundaries will improve data analysis.   When designing the hierarchy the number of children for any organisational unit may indicate the usefulness of the structure, e.g. having one or more  1-1 relationships between two levels is not very useful as the values will be the same for the child and the parent level. On the other extreme a very high number of children in the middle of the hierarchy (e.g. 50 districts in a province) might call for an extra level to be added in between  to increase the usefulness of data analysis. The lowest level, the health facilities will often have a large number of children (10-60), but for other levels higher up in the hierarchy approx. 5-20 children is recommended. Too few or too many children might indicate that a level should be removed or added.</para>
+      <para> Note that it is quite easy to make changes to the upper levels of the hierarchy at a later stage, the only problem is changing organisational units that collect data (the leaf nodes), e.g.  splitting or merging health facilities. Aggregation up the hierarchy is done based on the current hierarchy at any time and will always reflect the most recent changes to the organisational structure. Refer to the chapter on Organisation Units to learn how to create organisational units and to build up the hierarchy.</para>
     </section>
     <section>
       <title>Data Elements</title>