= Proposal for translation of configurable labels
== The Problem
We have translatable messages since Trac-0.12, even extended the i18n system towards configuration option doc-strings. But we're still missing translations in some rather prominent places.

== Currently untranslatable items
This is a list of items, that can't be localized yet (including related tickets):
 * Enum
  * ticket properties:
   * type
   * status (see configurable ticket workflow below)
   * priority
   * serverity
   * milestone (see below)
   * customized labels for standard fields (see #6249)
  * milestone label, used in tickets too
  * component name, used in tickets too
 * configurable ticket workflow
  * action name (see #9472)
  * ticket status, used in tickets and timeline as well, `new` and `closed` even hard-coded in ticket system code, including reports and custom queries (see #9799)
 * timeline
  * ticket changes (related to ticket status from work-flow above, see #5441)

Well, I guess this should be almost identical to MissingTranslations (listed by module), right?


== A possible solution
The following rough sketch of a suitable translation work-flow sprung from discussion on IRC tonight (25-Oct-2012):
 * `$> trac-admin <env> extract_custom_messages`
  a. produces a new file `env/htdocs/locale/trac_custom.pot` or
  b. updates an existing one
 * use similar standard procedures for PO files (more `trac-admin` commands here)
  * create new message catalogs for a language
  * update one/all existing messages catalogs
 * use standard procedures to edit message catalogs

=== Implementation details
The aforementioned work-flow implies, that custom message cataloges are rather volatile. But recompilation on Trac environment load should be avoided, because this could be rather time-consuming. So it must be possible to pre-compile them, i.e. with yet another `trac-admin` command.

=== Wishlist
(Order should matter)

 * auto-generated TRANSLATOR hints like
  `# ini:ticket-workflow` or `# enum:priority`
 * include a ''basic common'' set of typical terms, like work-flow action names from default ticket work-flow
 * detect changes, to remind for recompilation, if pending changes are detected, but PO (clear-text) and MO (compiled) message catalog files change time must be tracked like done for `trac.ini` to make this happen