Roundup Tracker - Issues

Issue 2551007

classification
Title: Selection fields are not translated
Type: behavior Severity: normal
Components: Web interface Versions: devel
process
Status: new Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: mathiasb, mbehrle, rouilj, schlatterbeck
Priority: Keywords:

Created on 2018-10-09 21:42 by mbehrle, last changed 2018-10-12 23:40 by mathiasb.

Messages
msg6267 Author: [hidden] (mbehrle) Date: 2018-10-09 21:42
In a fresh install of roundup from the mercurial repos all selection
fields are shown untranslated (running here under german localization).
msg6268 Author: [hidden] (mbehrle) Date: 2018-10-09 21:45
Note: installation is under Python3
msg6270 Author: [hidden] (rouilj) Date: 2018-10-09 21:52
Hi Mathias:

In message <1539121349.5.0.545547206417.issue2551007@psf.upfronthosting.co.za>,
Mathias Behrle writes:
>New submission from Mathias Behrle:
>
>In a fresh install of roundup from the mercurial repos all selection
>fields are shown untranslated (running here under german localization).

What do you mean by selection fields? The labels for selection boxes,
or the actual items that you select from the dropdown? Can you upload
a screenshot that shows the issue?

Thanks.
msg6272 Author: [hidden] (mbehrle) Date: 2018-10-09 22:12
* John Rouillard: " [issue2551007] Selection fields are not translated"
(Tue,
  09 Oct 2018 21:52:10 +0000):

Hi John,

> John Rouillard added the comment:
> 
> Hi Mathias:
> 
> In message
> <1539121349.5.0.545547206417.issue2551007@psf.upfronthosting.co.za>,
Mathias
> Behrle writes:
> >New submission from Mathias Behrle:
> >
> >In a fresh install of roundup from the mercurial repos all selection
> >fields are shown untranslated (running here under german localization).  
> 
> What do you mean by selection fields? The labels for selection boxes,
> or the actual items that you select from the dropdown? Can you upload
> a screenshot that shows the issue?

I mean the values of the selection box, not the label.

And indeed the issue appears on issue.item.html, not on issue.search.html.
This seems to indicate, that the problem could be caused by my local
templates.
I will try with the unchanged template from roundup and give feedback.
msg6274 Author: [hidden] (mbehrle) Date: 2018-10-09 22:20
I tried with vanilla issue.item.html and the problem persists.
msg6279 Author: [hidden] (mbehrle) Date: 2018-10-10 21:59
AFAIS the untranslated items are closely tied to

tal:replace="structure context/xxxxxxx...
msg6281 Author: [hidden] (rouilj) Date: 2018-10-11 01:05
Hi Mathias:

I'm including the dev list on this because my knowledge of
internationalization is not great.

Summary: Mathias needs help setting up a drop down/select where the
options are translated. He is running under python 3 from a mercurial
checkout.

Reference: http://issues.roundup-tracker.org/issue2551007

In page.html of the classic tracker's html directory there are two macros:

  search_select

and 

  search_select_translated

The major difference between them is how the options are generated.
search_select uses:

  <option tal:repeat="s python:db[db_klass].list()"
            tal:attributes="value s/id; selected python:value == s.id"
            tal:content="python:s[db_content]"></option>

while search_select_translated does:

  <option tal:repeat="s python:db[db_klass].list()"
            tal:attributes="value s/id; selected python:value == s.id"
            tal:content="python:s[db_content]"
            i18n:translate=""></option>

If I understand this, the 'i18n:translate=""' causes the templating
engine to look up the content of the option tag (which I think is the
displayed label) as a key in the translation table. Then it uses the
result of that look up as the content.

If the content string of the option doesn't exist in the translation
table the content is left untranslated.

From what info you have provided, I don't know if i18n:translate="" is
missing from the template's options statement or if there is no
translation for the option label. Either would result in what you see.

IIRC you mentioned that the search template does translate the items.
I would not expect the issue.search.html in the classic tracker
template to do that so I am kind of stumped.

Maybe this will give you an idea, or somebody on the dev list (I know
we have a number of people whose primary language is not English will
be able to help.

Have a great day.
msg6282 Author: [hidden] (schlatterbeck) Date: 2018-10-11 07:07
On Wed, Oct 10, 2018 at 09:05:30PM -0400, John P. Rouillard wrote:
> 
> while search_select_translated does:
> 
...
>             i18n:translate=""></option>

> If I understand this, the 'i18n:translate=""' causes the templating
> engine to look up the content of the option tag (which I think is the
> displayed label) as a key in the translation table. Then it uses the
> result of that look up as the content.
> 
> If the content string of the option doesn't exist in the translation
> table the content is left untranslated.

Yes, that's correct.

> >From what info you have provided, I don't know if i18n:translate="" is
> missing from the template's options statement or if there is no
> translation for the option label. Either would result in what you see.

That would also be my first guess, on the other hand this can also
be a bug introduced with python3 support.
So if the same (unmodified) templates worked with an earlier version
of roundup and no longer works now, I would expect this.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
msg6283 Author: [hidden] (mathiasb) Date: 2018-10-11 12:51
* Ralf Schlatterbeck: " Re: [Roundup-devel] [issue2551007] Selection fields are
  not translated" (Thu, 11 Oct 2018 09:07:43 +0200):

> On Wed, Oct 10, 2018 at 09:05:30PM -0400, John P. Rouillard wrote:
> > 
> > while search_select_translated does:
> >   
> ...
> >             i18n:translate=""></option>  
> 
> > If I understand this, the 'i18n:translate=""' causes the templating
> > engine to look up the content of the option tag (which I think is the
> > displayed label) as a key in the translation table. Then it uses the
> > result of that look up as the content.
> > 
> > If the content string of the option doesn't exist in the translation
> > table the content is left untranslated.  
> 
> Yes, that's correct.
> 
> > >From what info you have provided, I don't know if i18n:translate="" is  
> > missing from the template's options statement or if there is no
> > translation for the option label. Either would result in what you see.  
> 
> That would also be my first guess, on the other hand this can also
> be a bug introduced with python3 support.
> So if the same (unmodified) templates worked with an earlier version
> of roundup and no longer works now, I would expect this.
> 
> Ralf

Guys, thanks a lot for helping!

Indeed the main reason were lost translations in the po file. After re-creating
the po file and merging the old translations they now appear translated except
a few ones:

- all date/time values in column activity (yesterday, month ago, day, ago...)

- the first item in selection boxes which is '- no selection -' (encountered
  also when using the jinja2 templates - which I like very much btw.)

The latter item is translated and in the po file:

#: ../html/issue.item.html:122 ../html/issue.item.html:197
#: ../html/issue.item.html:220
msgid "- no selection -"
msgstr "- nichts ausgewählt -"

Cheers,
Mathias

-- 

    Mathias Behrle
    MBSolutions
    Gilgenmatten 10 A
    D-79114 Freiburg

    Tel: +49(761)471023
    Fax: +49(761)4770816
    http://www.m9s.biz
    UStIdNr: DE 142009020
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6
msg6284 Author: [hidden] (rouilj) Date: 2018-10-11 21:48
Hi Mathias:

In message <20181011145128.2afb36f1@monsterix.mbehrle.de>,
Mathias Behrle writes:
>* Ralf Schlatterbeck: " Re: [Roundup-devel] [issue2551007] Selection fields
>   are not translated" (Thu, 11 Oct 2018 09:07:43 +0200):
>> On Wed, Oct 10, 2018 at 09:05:30PM -0400, John P. Rouillard wrote:
>> > 
>> > while search_select_translated does:
>> ...
>> >             i18n:translate=""></option>  
>> > [...]
>> > If the content string of the option doesn't exist in the translation
>> > table the content is left untranslated.  
>> 
>> Yes, that's correct.
>> 
>> > >From what info you have provided, I don't know if i18n:translate="" is  
>> > missing from the template's options statement or if there is no
>> > translation for the option label. Either would result in what you see.  
>> 
>> That would also be my first guess, on the other hand this can also
>> be a bug introduced with python3 support.
>> So if the same (unmodified) templates worked with an earlier version
>> of roundup and no longer works now, I would expect this.
>
>Indeed the main reason were lost translations in the po file. After
>re-creating the po file and merging the old translations they now
>appear translated

Do you have the exact steps you took to do this?

Ralf should we open a ticket to do this and check the changes into
mercurial?

> except a few ones:
>- all date/time values in column activity (yesterday, month ago, day,
>  ago...)

Hmm, I see:

  #: ../roundup/date.py:854
  msgid "yesterday"
  msgstr "gestern"

in de.po as well as translations for tomorrow, "just
now". Translations for days seem to be of the form %(number)s days
not just "day". I am not sure if this is a problem with the strings
not being marked for extraction or some other issue.

>- the first item in selection boxes which is '- no selection -'
>  (encountered also when using the jinja2 templates - which I like very
>  much btw.)
>
>The latter item is translated and in the po file:
>
>#: ../html/issue.item.html:122 ../html/issue.item.html:197
>#: ../html/issue.item.html:220
>msgid "- no selection -"
>msgstr "- nichts ausgewählt -"

I see:

  #: ../roundup/cgi/templating.py:1929
  #, python-format
  msgid "<option %svalue=\"-1\">- no selection -</option>"
  msgstr "<option %svalue=\"-1\">- nichts ausgewählt -</option>"

in locale/de.po, so not quite the same.
msg6286 Author: [hidden] (mathiasb) Date: 2018-10-12 23:40
* John Rouillard: " [issue2551007] Selection fields are not translated" (Thu,
  11 Oct 2018 21:48:15 +0000):

Hi John,

> In message <20181011145128.2afb36f1@monsterix.mbehrle.de>,
> Mathias Behrle writes:
> >* Ralf Schlatterbeck: " Re: [Roundup-devel] [issue2551007] Selection fields
> >   are not translated" (Thu, 11 Oct 2018 09:07:43 +0200):  
> >> On Wed, Oct 10, 2018 at 09:05:30PM -0400, John P. Rouillard wrote:  
>  [...]  
> >> ...  
>  [...]  
>  [...]  
> >> 
> >> Yes, that's correct.
> >>   
>  [...]  
>  [...]  
> >> 
> >> That would also be my first guess, on the other hand this can also
> >> be a bug introduced with python3 support.
> >> So if the same (unmodified) templates worked with an earlier version
> >> of roundup and no longer works now, I would expect this.  
> >
> >Indeed the main reason were lost translations in the po file. After
> >re-creating the po file and merging the old translations they now
> >appear translated  
> 
> Do you have the exact steps you took to do this?

Basically it was:

# Create new messages.pot
roundup-gettext <tracker-home>

# Add strings from other files in tracker home
xgettext -a -j -o locale/messages.pot initial_data.py
xgettext -a -j -o locale/messages.pot schema.py

# Update po from catalog
poedit de.po
Catalog/Update from messages.pot

# Merge old translations:
msgcat --use-first -o update.po ../../../roundup/locale/de.po ./de.po
[./de.po.new]
 -> this creates a new file update.po from the indicated source files with
 preference of translations from the roundup translations

# [Optional]: Delete obsolete entries:
msgmerge update.po messages.pot | msgattrib --no-obsolete > de.po

> Ralf should we open a ticket to do this and check the changes into
> mercurial?
> 
> > except a few ones:
> >- all date/time values in column activity (yesterday, month ago, day,
> >  ago...)  
> 
> Hmm, I see:
> 
>   #: ../roundup/date.py:854
>   msgid "yesterday"
>   msgstr "gestern"
> 
> in de.po as well as translations for tomorrow, "just
> now". Translations for days seem to be of the form %(number)s days
> not just "day". I am not sure if this is a problem with the strings
> not being marked for extraction or some other issue.
>
> >- the first item in selection boxes which is '- no selection -'
> >  (encountered also when using the jinja2 templates - which I like very
> >  much btw.)
> >
> >The latter item is translated and in the po file:
> >
> >#: ../html/issue.item.html:122 ../html/issue.item.html:197
> >#: ../html/issue.item.html:220
> >msgid "- no selection -"
> >msgstr "- nichts ausgewählt -"  
> 
> I see:
> 
>   #: ../roundup/cgi/templating.py:1929
>   #, python-format
>   msgid "<option %svalue=\"-1\">- no selection -</option>"
>   msgstr "<option %svalue=\"-1\">- nichts ausgewählt -</option>"
> 
> in locale/de.po, so not quite the same.

I will have to re-check, if there are not matching msgid's.

-- 

    Mathias Behrle
    MBSolutions
    Gilgenmatten 10 A
    D-79114 Freiburg

    Tel: +49(761)471023
    Fax: +49(761)4770816
    http://www.m9s.biz
    UStIdNr: DE 142009020
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6
History
Date User Action Args
2018-10-12 23:40:25mathiasbsetmessages: + msg6286
2018-10-11 21:48:15rouiljsetmessages: + msg6284
2018-10-11 12:51:42mathiasbsetnosy: + mathiasb
messages: + msg6283
2018-10-11 07:07:48schlatterbecksetnosy: + schlatterbeck
messages: + msg6282
2018-10-11 01:05:51rouiljsetmessages: + msg6281
2018-10-10 21:59:02mbehrlesetmessages: + msg6279
2018-10-09 22:20:54mbehrlesetmessages: + msg6274
2018-10-09 22:13:00mbehrlesetmessages: + msg6272
2018-10-09 21:52:10rouiljsetnosy: + rouilj
messages: + msg6270
2018-10-09 21:45:35mbehrlesetmessages: + msg6268
2018-10-09 21:42:29mbehrlecreate