Separate translation domain for log messages
If we want to i18n log messages, I think they should be in a separate translation domain from the messages we return to users of the REST API.
The problem with having them both in the same translation domain is that translators have no way of prioritizing the REST API messages nor do administrators have any way of disabling the translation of log messages without the translation of the REST API messages.
Blueprint information
- Status:
- Complete
- Approver:
- Mark McLoughlin
- Priority:
- High
- Drafter:
- Mark McLoughlin
- Direction:
- Approved
- Assignee:
- Doug Hellmann
- Definition:
- Approved
- Series goal:
- Accepted for icehouse
- Implementation:
-
Implemented
- Milestone target:
-
2014.1
- Started by
- Doug Hellmann
- Completed by
- Doug Hellmann
Related branches
Related bugs
Sprints
Whiteboard
Related etherpad - https:/
Some initial examples of how we might do this: http://
Un-assigning myself from this for now -- markmc
Additional details discussed in https:/
Gerrit topic: https:/
Addressed by: https:/
Add support for translating log levels separately
Addressed by: https:/
Update oslo log messages with translation domains
this bp still has many items in TODO and patches waiting for review. Moving to i-3
During the team meeting 2014-01-31 we agreed to skip translating DEBUG messages entirely for now, and consider adding them back later if operators need them. http://
Addressed by: https:/
Update oslo log messages with translation domains
Gerrit topic: https:/
Addressed by: https:/
Update log translation domains
----
The code for this is in place in oslo-incubator, but we need to update the build steps that manage the catalogs. I'm not sure that's a good idea, this close to the string freeze, so we may have to wait to roll out this work during the juno cycle. - dhellmann
Addressed by: https:/
Use _LI instead of _ for info message translation
Work Items
Work items:
create new translation functions in gettextutils: DONE
write tests for them, including lazy and non-lazy scenarios: DONE
update the incubator code to use the new functions for log message translation: DONE
document how to use the new functions in LoggingStandards (and announce on the ML): TODO
clean up the translation related jobs in infra: TODO
loop over the log levels to extra messages for all of them: TODO
loop over the log levels to register the new resources with transifex: TODO
loop over the log levels to update the catalogs: TODO
Dependency tree
* Blueprints in grey have been implemented.
