diff --git a/docs/customizing.htm b/docs/customizing.htm index 8d8d650e..037194bf 100644 --- a/docs/customizing.htm +++ b/docs/customizing.htm @@ -807,6 +807,16 @@ db_manager.getSql("SELECT SUM(rain) FROM %s "\ [[[Labels]]] / [[[[Generic]]]] Highest precedence. Has the final say. + + skins/report_name/ lang/language_code.conf + + Affects only the report report_name. + [Labels] / [[Generic]] + Internationalization support. Preferably + supplied by the skin author. + weewx.conf [StdReport] / [[Defaults]] @@ -884,6 +894,46 @@ db_manager.getSql("SELECT SUM(rain) FROM %s "\ wants to use the string Exterior Temperature, instead of Outside Temperature for the label for outTemp. The file includes no definition for inTemp.

+ +

+ Now suppose the skin author took care of internationalization + and provided language files. In this case s/he would not have + set the label in skin.conf but in + a language file, for English in + lang/en.conf, for german in + lang/de.conf etc. +

+

+ lang/en.conf would contain + what was defined in skin.conf + before: +

+
+...
+[Labels]
+    ...
+    [[Generic]]
+        ...
+        outTemp = Exterior Temperature
+
+

+ lang/de.conf would contain: +

+
+...
+[Labels]
+    ...
+    [[Generic]]
+        ...
+        outTemp = Außentemperatur
+        inTemp = Innentemperatur
+
+

+ The user sets the language by the optional + lang option in + weewx.conf. +

+

Finally, for purposes of illustrating precedence, suppose the [StdReport] section of weewx.conf contains this: @@ -904,6 +954,10 @@ db_manager.getSql("SELECT SUM(rain) FROM %s "\ [[[Labels]]] [[[[Generic]]]] outTemp = Barn Temperature + + [[LifeC]] + skin = Life + lang = de

@@ -931,20 +985,31 @@ db_manager.getSql("SELECT SUM(rain) FROM %s "\ Inside Temperature Barn Temperature + + LifeC + Innentemperatur + Außentemperatur +

- Note how the values specified for inTemp are not overridden anywhere, so the value + Note how the values specified for inTemp + are not overridden anywhere, except + lang/de.conf, so the value specified in weewx/defaults.py, that is, Inside Temperature, is used for all reports.

+ class="code">Inside Temperature, is used for all reports, + except LifeC.

The value for outTemp is not overridden for report SeasonsA, so it uses the label specified in weewx/defaults.py, that is, Outside Temperature. By contrast, for the "Life" reports, a value for outTemp was specified in the skin so, in the absence of any user override, its value, Exterior - Temperature will be used as the new default. Finally, for the report LifeB, + Temperature will be used as the new default. For the report LifeB, the user has specified an override for outTemp, so that value, Barn Temperature, is used. + Finally, for the report LifeC + a language has been set, so the labels are taken from the + specified language file.

@@ -1119,7 +1184,40 @@ db_manager.getSql("SELECT SUM(rain) FROM %s "\

To accomplish this, we will generate two reports, one using the defaults, the other using overrides to - change the target unit system and the target directory. The section [StdReport] + change the target unit system and the target directory. +

+

+ If you only want to use one of the predefined unit systems + like US or + METRIC you can simply specify + a unit system in the report configuration like this: +

+
+[StdReport]
+
+    # Where the skins reside, relative to WEEWX_ROOT
+    SKIN_ROOT = skins
+
+    # Where the generated reports should go, relative to WEEWX_ROOT
+    HTML_ROOT = public_html
+
+    # The database binding indicates which data should be used in reports.
+    data_binding = wx_binding
+
+    [[SeasonsUSReport]]
+        skin = Seasons
+        target_unit = US
+        enable = true
+
+    [[SeasonsMetricReport]]
+        skin = Seasons
+        target_unit = METRIC
+        enable = true
+        HTML_ROOT = public_html/metric
+

+ If you need individual settings for a lot of units you + can specify the units directly in the report configuration. + In this case the section [StdReport] will look like this:

@@ -2928,6 +3026,79 @@ $month.outTemp.series(aggregate_type='max', aggregate_interval='day', time_serie
             Tags for series.
         

+

General tags

+ +

+ There are some general tags, that do not reflect observation + data but technical data of processing the template files. + You can especially use them in #if + expressions to control how Cheetah processes the template. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TagDescription
$month_nameName of the month, the file is created for
$year_nameYear, the file is created for
$encodingCharacter encoding, to which the file is converted + after creation. Possible values are + html_entities, + strict_ascii, + normalized_ascii, and + utf-8. +
$pageName of the page that is actually processed. + This is the section name from + skin.conf + where the template is described. You can especially + use it in include files that are included in multiple + templates. So parts of the content defined in the include + file can depend on the template file, for example + header lines. You can also use it together with + $gettext to structure + the language file.
$gettext.langLanguage code set by the + lang option + for the report. You can use this tag in + #if expressions and + to include language codes where the HTML + specification requires them. +
$gettext(page=$page).template + File name of the template actually processed +
+ + +

+ Internationalization support with + $gettext +

+ +

+ +

+

Almanac