If using Babel 1.x, I've caught the same issue and filed in http://trac.edgewall.org/ticket/11345. On Wed, Nov 20, 2013 at 3:46 AM, Ryan Ollos wrote: > On Tue, Nov 19, 2013 at 10:33 AM, Saint Germain wrote: > >> On Tue, 19 Nov 2013 12:40:50 -0500, Olemis Lang >> wrote : >> > > b) In the Custom Query page, the checkboxes "accepted, assigned, >> > > closed, needinfo, etc." are still in english (I don't know where the >> > > names are defined) >> > > >> > >> > I've spotted a situation that might require our attention during i18n >> > process. In many templates there are embedded widgets e.g. >> > >> > {{{#!xml >> > >> > >> > >> > Components >> > component >> > true >> > > > name="query">product=${product.prefix}&group=component >> > >> > >> > }}} >> > >> > In such cases some parameters should be translated (e.g. `title` in >> > sample widget above) whereas other do not . Depending on the behavior >> > of the Genshi i18n extractor something should be done about this in >> > order to either : >> > >> > - Force detection of language-dependent strings e.g. ''Components'' >> > - Do not include neutral strings in translation catalog >> > >> > Have you noticed such issues in the dashboard ? >> >> No I haven't made a lot of test on the UI. I figured that I should try >> first to translate everything in the .po file and then see in the UI >> where the translations are missing. Agreed, it may not be the smartest >> way to proceed. ;-) >> >> I'll try to have a a look. >> >> There is also something wrong with the strings extractor. If you take a >> look at the remaining strings to translate in french in Transifex, >> you'll see that there are just some code/variables which don't need to >> be translated. >> I haven't managed so far to figure why they are extracted. >> >> >> > > 3) In case of problem in the translation process, the stack trace is >> > > very difficult to understand. For example I had a problem with a new >> > > version of Babel and the result was something like >> > > "NullTranslationsBabel has no attribute isactive". I will propose >> > > some more try/request on trac/trac/util/translation.py in order to >> > > have a more useful debug log >> > > >> > >> > @rjollos : will this be a useful addition to the Trac core ? >> > >> >> It is not something revolutionary. >> For instance (just a silly example): >> >> diff -r 15e5b368262d trac/trac/util/translation.py >> --- a/trac/trac/util/translation.py Tue Nov 19 03:23:37 2013 +0100 >> +++ b/trac/trac/util/translation.py Tue Nov 19 19:29:01 2013 +0100 >> @@ -156,7 +156,10 @@ >> domains = self._plugin_domains.get(env_path, {}) >> domains = domains.items() >> for domain, dirname in domains: >> - t.add(Translations.load(dirname, locale, domain)) >> + try: >> + t.add(Translations.load(dirname, locale, >> domain)) >> + except Exception: >> + raise ValueError("Error adding %s %s %s" % >> (dirname,locale,domain)) >> self._current.translations = t >> self._activate_failed = False >> >> Indeed if there is no try/catch at this point and there is an error in >> Babel, >> then the property isactive of TranslationsProxy throw an exception and the >> result >> is an error message saying that isactive is not a property... >> > > Babel 0.9.6 is what is specified in the pip requirements file, is that the > version of Babel you are running? There is an issue with later versions of > Babel that looks similar to what you are reporting, and it has been fixed > for the forthcoming Trac 1.0.2: > > http://trac.edgewall.org/ticket/10903#comment:5 -- Jun Omae (大前 潤)