Commit 434aa6ed authored by Philip Withnall's avatar Philip Withnall

internationalization: Add monospace in various places

This got lost during the conversion from ODT.
Signed-off-by: default avatarPhilip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: default avatarMathieu Duponchelle <mathieu.duponchelle@collabora.co.uk>
Differential Revision: https://phabricator.apertis.org/D4029
parent faecf76c
......@@ -48,8 +48,9 @@ that input method framework.
Note that currently there is almost no support in Clutter for using
input methods. Lead Clutter developer Emmanuele Bassi recommends doing
something similar to GNOME Shell, which uses [GtkIMContext] on top of
[ClutterText][StEntry], which would imply depending on GTK+. There's a project
something similar to GNOME Shell, which uses [`GtkIMContext`][GtkIMContext] on
top of
[`ClutterText`][StEntry], which would imply depending on GTK+. There's a project
called clutter-imcontext that provides a simple version of GtkIMContext
for use in Clutter applications, but Emmanuele strongly discourages its
use. GTK+ and Qt support XIM, SCIM and IBus.
......@@ -58,17 +59,17 @@ In order to add support for GtkIMContext to ClutterText, please see how
it's done in [GNOME Shell][st-im-text]. As can be seen this implementation calls
the following functions from the [GtkIMContext] API:
- gtk\_im\_context\_set\_cursor\_location
- `gtk_im_context_set_cursor_location`
- gtk\_im\_context\_reset
- `gtk_im_context_reset`
- gtk\_im\_context\_set\_client\_window
- `gtk_im_context_set_client_window`
- gtk\_im\_context\_filter\_keypress
- `gtk_im_context_filter_keypress`
- gtk\_im\_context\_focus\_in
- `gtk_im_context_focus_in`
- gtk\_im\_context\_focus\_out
- `gtk_im_context_focus_out`
Between the code linked above and the GTK+ API reference it should be
reasonably clear how to add GtkIMContext support to Clutter
......@@ -85,7 +86,7 @@ of UI toolkits, Collabora recommends it to use IBus.
The reasons for recommending to use an input-method framework is that
most toolkits have support for it, so if an application is reused that
uses Qt, the on-screen keyboard will be used without any specific
modification, which wouldn't be the case if GtkIMContext would be used.
modification, which wouldn't be the case if `GtkIMContext` would be used.
About why to use IBus over other input-method frameworks, the reason is
that IBus is already supported by most modern toolkits, has a very
......@@ -149,7 +150,7 @@ from several file formats into PO files.
It is most common in FOSS projects (specially those using GNU gettext)
to use the English translation as the identifier for the occurrence of a
piece of text that needs to be translated, though some projects use an
identifier that can be numeric (T54237) or a mnemonic (PARK\_ASSIST\_1).
identifier that can be numeric (`T54237`) or a mnemonic (`PARK_ASSIST_1`).
The IDs will not leak to the UI if the translations are complete, and
there is also the possibility of defining a fallback language.
......@@ -158,10 +159,9 @@ plain English as the ID:
- so that when the English translation is changed in a trivial way,
that message isn't marked as needing review for all other languages;
- and to avoid ambiguities, as “Stop” may refer to an action or a
state and thus may be translated differently in some languages,
while using the IDs “state\_stop” and “action\_stop” would remove
while using the IDs `state_stop` and `action_stop` would remove
that ambiguity.
When using gettext, the first argument loses some strength as it
......@@ -208,8 +208,8 @@ Instead of having to specify whole font descriptions for each string to
translate, Collabora recommends to use styles that expand to specific
font descriptions.
Here is an example of such a metadata file, note the font styles NORMAL,
TITLE and APPLICATION\_LIST:
Here is an example of such a metadata file, note the font styles `NORMAL`,
`TITLE` and `APPLICATION_LIST`:
```
PARK_ASSIST_1 NORMAL 120px
......@@ -314,7 +314,7 @@ are marked as needing review. If strings are indexed with unique IDs
instead of the English translation, then it's recommended to use the
--no-fuzzy-matching option to msgmerge, so new IDs will be always empty.
Otherwise, if the POT file contained already an entry for
PARK\_ASSIST\_1 and PARK\_ASSIST\_2 was added, when merging into
`PARK_ASSIST_1` and `PARK_ASSIST_2` was added, when merging into
existing translations, the existing translation would be reused, but
marking the entry as fuzzy (which would cause Transifex to use that
translation as a suggestion).
......@@ -322,14 +322,14 @@ translation as a suggestion).
#### Translation management
Though these file generation steps can be executed manually with command
line tools and translators can work directly on the .po files with any
line tools and translators can work directly on the `.po` files with any
text editor, there are more high-level tools that aim to manage the
whole translation process. Next we briefly mention the ones most
commonly used in FOSS projects.
[Pootle], [Transifex] and Launchpad [Rosetta] are tools
which provide convenient UIs for translating strings. They also
streamline the process of translating strings from new .pot versions and
streamline the process of translating strings from new `.pot` versions and
offer ways to transfer the resulting .po files to source code
repositories.
......@@ -506,10 +506,10 @@ synthetic).
When calculating the length of a translation for a string that contains
one or more [printf placeholders], the width that the string can
require when displayed in the UI grows very quickly. For example, for
the placeholder *%d* which can display a 32-bit integer value, the final
the placeholder `%d` which can display a 32-bit integer value, the final
string can take up to 10 additional digits. The only way to be safe is
to assume that each placeholder can be expanded to its maximum size,
though in the case of strings (placeholder *%s*) that is practically
though in the case of strings (placeholder `%s`) that is practically
unlimited.
If, despite automatically warning the translator when a translation will
......@@ -549,13 +549,13 @@ Our recommendation at this stage is to have:
- each application along with all its existing translations in a
single package. This way the user will install e.g.
navigation-helper\_1.10\_armhf.deb and the user will be able to
`navigation-helper_1.10_armhf.deb` and the user will be able to
switch between all the supported languages without having to install
any additional packages.
- the rest of the MO files (those belonging to the UI that is
pre-installed, such as applications and the shell) would be packaged
grouped by language, e.g. apertis-core-de\_2.15\_armhf.deb. That way
grouped by language, e.g. `apertis-core-de_2.15_armhf.deb`. That way
we can choose which languages will be pre-installed and can allow
the user to install additional languages on demand.
......@@ -617,19 +617,19 @@ that there isn't an excessive amount of actors in the stage.
![](./media/switching_locale_sequence.png)
LocaleManager in the diagram would be a singleton that stores the
`LocaleManager` in the diagram would be a singleton that stores the
current locale and notifies interested parties when it changes. The
current locale would be changed by UI elements such as a combo-box in
the settings panel, a menu option, etc.
Other UI elements that take locale-dependent decisions (in the diagram,
SettingsWindow) would register to be notified when the locale changes,
`SettingsWindow`) would register to be notified when the locale changes,
so they can change their UI (update strings, change icons, change text
orientation, etc.).
If the UI element that changes the current locale and the UI elements
that have to be updated don't reside in the same operating system
process, LocaleManager could be a D-Bus service whose API would include
process, `LocaleManager` could be a D-Bus service whose API would include
the capability to set and get the current locale and be notified of
changes.
......@@ -675,21 +675,21 @@ _retranslate_ui (ExampleBluetoothSettingsDialog *self)
To reduce the amount of work that most application authors will have
when making their applications aware of runtime locale switches, we
recommend that the SDK API includes a subclass of ClutterText (let's
call it for now ExampleText) that reacts to locale changes.
recommend that the SDK API includes a subclass of `ClutterText` (let's
call it for now `ExampleText`) that reacts to locale changes.
ExampleText would accept a translatable ID via the function
example\_text\_set\_text(), would display its translation based on the
`ExampleText` would accept a translatable ID via the function
`example_text_set_text()`, would display its translation based on the
current locale and would also listen for locale changes and update
itself accordingly.
So xgettext can extract the string IDs that get passed to ExampleText,
So xgettext can extract the string IDs that get passed to `ExampleText`,
it would have to be invoked with
--flag=example\_text\_set\_text:1:c-format.
`--flag=example_text_set_text:1:c-format`.
If applications use ExampleText instead of ClutterText for the display
If applications use `ExampleText` instead of `ClutterText` for the display
of all their translatable text, they will have to interface with
LocaleManager only if they have to localize other aspects such as icons
`LocaleManager` only if they have to localize other aspects such as icons
or container orientation.
## Localization in GNOME
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment