bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Whitelabeling: Messages
Date Tue, 13 Nov 2012 15:05:29 GMT
There is a lot of use of the word "Trac" inside various error messages,
descriptions and user instructions that are shown to the user either
through web UI or responses in CLI tools. All cases are in the Trac itself.

There are two groups of messages:

*** Messages hardcoded in python source ***

There are over 200 instances of word Trac in python strings. Large portion
is in docstrings which we can leve as they are.
A few tens of them are actually strings intended for the uses in printouts,
error messages, option descriptions and the like.

Fixing this would be beneficial but is not of a high priority and would
complicate merging of newer Trac versions quite a bit and at the same time
this is not something we could push back to Trac project. I'll create a low
priority ticket for this so that we have it on radar unless there are some
objections to fixing them at all.

*** Messages in localization files ***

There are 70+ localized messages and over 30 localized languages.

Again, this is not fixable without changing the Trac project. In addition
to problems with merging (although smaller that with hardcoded messages) we
would also have to maintain language translations for all supported
languages. I'll open a low priority ticket for this as well if there are no

*** TracError title ***

This is actually just on of the cases of a message from localization
files. Proper solution is not any less messy as for any other message
(hacked localization files for all languages).  The question is do we want
to fix it even if we choose not to fix all other localizable messages due
to higher frequency of use?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message