118
edits
Bugzilla:L10n:Roadmap: Difference between revisions
Jump to navigation
Jump to search
→Localizable database data: database l10n described
(Initial revision) |
(→Localizable database data: database l10n described) |
||
| Line 16: | Line 16: | ||
** Fields which should be displayed on user's language. In 3.0, ''Status'' and ''Resolution'' translations are supported. | ** Fields which should be displayed on user's language. In 3.0, ''Status'' and ''Resolution'' translations are supported. | ||
* Dependent fields | * Dependent fields | ||
** Not directly translatable, some fields may still take different values depending of language. For example, default assignee is expected to read initial description. QA may communicate with reporter to confirm resolution. Both fields may need to take different values if reporter uses localized interface to file a bug. | ** Not directly translatable, some fields may still take different values depending of language. For example, default assignee is expected to read initial description. QA may communicate with reporter to confirm resolution. Both fields may need to take different values if reporter uses localized interface to file a bug. | ||
=== More translatable fields === | === More translatable fields === | ||
{{Bug|406222}} applies the same TT tools to translate ''Severity'', ''Platform'', ''OS'', and values of setup parameters. | {{Bug|406222}} applies the same TT tools to translate ''Severity'', ''Platform'', ''OS'', and values of setup parameters. | ||
However, this leads us nowhere: if localizers move to gettext, site customization would require extra skills, beyond Template Toolkit. | |||
=== Generic database level field translation === | |||
A better approach would be: | |||
''Content should be localized same way it was created.'' That is, UI features to be translates in templates, and database fields -- in other database fields. | |||
This requires some careful design however. Adding LANG value as unique key component to some tables may hurt 3NF. Adding new detail tables (key, LANG, text) will require a lot of compatibility views. Default language fallback may severely hurt performance if implemented in straightforward fashion on a query level. | |||
== l10n unification == | == l10n unification == | ||