I tried to translate some message in date.py ("Not a date spec...") but 
found no effect. 

It seems that "translator" argument in __init__ Date function never get a 
real value but always default. The default value comes from roundup.i18n 
module and has no relation with tracker "language" setting. 

So i'm confused how to fix this.

Hi Anthony,
the i18n module only loads .mo files it can find (or create from .po files it 
found). Reading the code it seems that in the default case it only 
searches in some places, depending on where roundup is installed.

You can see the place it searches with the following test:

python
>>> import roundup.i18n as i
>>> i.LOCALE_DIRS
['/usr/share/locale', '../../../share/locale']

Place your ..mo or .po files there or temporarily patch 
the beginning of i18n.py.

To get a German "de" translation for demo.py I did something like
added ".locale" to LOCALE_DIRS in the top of i18n.py
and then copied the .po files to the right place (roundup compiles it then).
  mkdir -p ./locale/de/LC_MESSAGES
  cp ./locale/de.po ./locale/de/LC_MESSAGES/
  python demo.py

Let me know if this solves your case.
And please also suggest a hint for improvement of the documentation.

Hi Bernhard.

Thank you for your suggestion, but it is a different case.

I have translation (.mo) correctly installed and it is loaded by 
roundup instance. But messages from date.py always remain in english 
while other translations works well.

So, if you translate "Not a date spec..." message you will never see 
it. It can be proven by entering wrong date in date field.

Hi Anthony,

looks like we are facing a mystery. Why would it work
on other message, but not on this one? My first idea:
a) a wrong message has been translated, there is small difference
b) the message comes from a different place.

Otherwise you'd probaly have to track within the i18n module to see if this 
is actually called and by with strings.
Bernhard

Hi Bernhard.

I think this is a common problem. You can translate the message "Not a 
date spec..." to any language and it will not work, i guess. I want to 
specify that this is a problem of date.py module. Messages from this 
module never appear translated.

Let me expand the problem.

Date class get "translator" variable in it constructor. "_" function 
assigned in constructor to "translator"'s gettext. Default value for 
"translator" is i18n from i18n.py module.

While creating Date instance the "translator" value left to default 
i18n class. Unfortunately, i18n class does not use trackers "language" 
setting and always stay in english.

Thus:
1. Real "translator" value does not pass to Date instance.
2. Default i18n instance have no relation to tracker "language" setting.

Other objects (not a Date) get real "translator" value from the tracker 
instance, i suspect.

> Let me expand the problem.

If you did some analysis, could you provide a patch?

Unfortunately i'm not shure how to do it in right roundup way.

1. About date.py.

I didn't catch where Date objects are created. So i don't know how to 
pass "translator" to them.

2. About i18n.py module. Make it sense tracker language setting.  
(quick fix)

It will sense setting if we replace
def get_translation(language=None, ...
to 
def get_translation(language=tracker.config["language"], ...

The problem is that there is no global variable of tracker instance 
("tracker"). It located somewhere in startup shell like roundup-server. 
The worse is if we'll add global tracker variable in instance.py we get 
circular reference.
So i don't know how to get tracker setting in i18n.py.

On Monday 16 December 2013 at 16:02:45, Anthony wrote:
> I didn't catch where Date objects are created. So i don't know how to
> pass "translator" to them.

As it works for other objects, I wonder what is different with Date objects.
Maybe a per-tracker-instance variable is needed in date.py when the 
configuration is done. Sorry for not being precise, I am trying to help, but 
I am not very familiar with the i18n architecture of roundup.

Attached patch against roundup snap code fix the problem.
It also fix some accompanied translation problem.

After applying you need to rebuild translation file roundup.pot (in
roundup source: cd locale && gmake template). Also you may need to merge
existing translation with new roundup.pot by something like 'msgcat
--use-firest roundup.pot de.po > de_new.po'.

In your language translation filde find a pattern 
  In apropriate language file find:
"'''^
((?P<y>\d\d\d\d)([/-](?P<m>\d\d?)([/-](?P<d>\d\d?))?)? # yyyy[-mm[-dd]]
|(?P<a>\d\d?)[/-](?P<b>\d\d?))?              # or mm-dd
(?P<n>\.)?                                   # .
(((?P<H>\d?\d):(?P<M>\d\d))?(:(?P<S>\d\d?(\.\d+)?))?)?  # hh:mm:ss
(?P<o>[\d\smywd\-+]+)?                       # offset
$'''"
 and replace it to desired expression which will parse your country
specific date/time format.
  Regular expression must contain y,m,d group for full date, a,b - for
m-d variant, n for now, o for offset,H,M,S for time.
  Also translate message '.. not a date / time spec ...' from date.py to
something which describe date/time format.

For reference also see issue2550871 for a similar patch.