bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saint Germain <saint...@gmail.com>
Subject Re: Internationalization of Bloodhound
Date Tue, 19 Nov 2013 18:33:20 GMT
On Tue, 19 Nov 2013 12:40:50 -0500, Olemis Lang <olemis@gmail.com>
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
> 
> <bh:widget urn="TicketFieldValues">
>    <bh:args>
>     <bh:arg name="title">Components</bh:arg>
>     <bh:arg name="field">component</bh:arg>
>     <bh:arg name="verbose">true</bh:arg>
>     <bh:arg
> name="query">product=${product.prefix}&amp;group=component</bh:arg>
>    </bh:args>
> </bh:widget>
> }}}
> 
> 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...

Mime
View raw message