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 "\
+ 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 "\
- 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.
+
+ | Tag | +Description | +
| $month_name | +Name of the month, the file is created for | +
| $year_name | +Year, the file is created for | +
| $encoding | +Character encoding, to which the file is converted + after creation. Possible values are + html_entities, + strict_ascii, + normalized_ascii, and + utf-8. + | +
| $page | +Name 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.lang | +Language 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 + | +
+ +
+