In a fresh install of roundup from the mercurial repos all selection
fields are shown untranslated (running here under german localization).

Note: installation is under Python3

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.

* 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.

I tried with vanilla issue.item.html and the problem persists.

AFAIS the untranslated items are closely tied to

tal:replace="structure context/xxxxxxx...

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.

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

* 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

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.

* 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

I have updated release documents to include merging newly generated .pot 
file into ,po files and create .mo files as part of release.mo file.

Mathias has your issue been solved, if so I'll close this issue.

* John Rouillard: " [issue2551007] Selection fields are not translated" (Wed,
  10 Jul 2019 23:33:56 +0000):

Hi John,

> I have updated release documents to include merging newly generated .pot 
> file into ,po files and create .mo files as part of release.mo file.
> 
> Mathias has your issue been solved, if so I'll close this issue.

Thanks for your continued work on roundup!

I just can't check immediately, will have to test with a fresh vanilla roundup.
I am just now running with some workarounds for default values of selection
fields and also for tal:content="i/activity/reldate" which did not work.

I will try to test ASAP, perhaps best to leave the issue still open a little
bit.

Mathias, were you able to confirm that things are fixed?

-- rouilj

* John Rouillard: " [issue2551007] Selection fields are not translated" (Sat,
  09 Nov 2019 21:46:35 +0000):

> John Rouillard added the comment:
> 
> Mathias, were you able to confirm that things are fixed?

Hello John,

sorry, I am currently unable to perform the necessary tests. Let's close the
issue, I can re-open in case it still exists.

Thank you for your continued work on roundup!

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

I found the following in cgi/translate.py

        k = linkcl.labelprop(1)

        if value:
            l.append('<option value="%s">- no selection -</option>'
                     % ','.join(['-' + v for v in value]))

        if additional:

This looks like it may be the source of the untranslated
'- no selection -' Mathias reported. I don't quite know what
this is doing, or how to mark it for translation.
I am marking it as a FIXME in the code and referencing this ticket.

I didn't find any other '- no selection -' strings in a grep though
the templates and code.

date.py has strings like yesterday, tomorrow, and '%s weeks'
surrounded by _(...) or using ngettext. So not sure what's happening
there.

Updated RELEASE.txt with better doc on generating .po files.

Closing.

Just to give feedback, sorry for being late: I tested now an install of 
2.0.0 and the issue indeed is solved.

Thank you!

Thanks for the confirmation Mathias.