> 42[Y] 11[M] 9[D]

Going back to this representation, I think is the best approach.
Easy to split and get elements, and it could allow more than 1 char, although I also think that translation should be kept to 1 character.

Question.. how about non-ascii chars, and non-latin representation? (like in the case of Chinese..) Can we represent it with a single char?
Today we have the ascii-escaped representation, that would take more than one char.

We'll go back to the debate on ensure_ascii argument in json.dumps. Let's explore this more.

Best
Luis
 

comment #4:

> I did update the DB but with health_gyneco from last refresh. Funny the "h" :)

I have found the reason, update health is needed, if not:

gettext('health.msg_compute_age_from_dates_year_str') = 'health.msg_compute_age_from_dates_year_str'

so

gettext('health.msg_compute_age_from_dates_year_str')[0] = 'h'   :-)

>
> Since it's a new feature, we'll move it to a task to incorporate in 4.4
>
> We have to check things such as the translated string does not take more than 1 char and things like that.

At the moment, I use gettext('health.msg_compute_age_from_dates_year_str')[0], so alway get a char string, if a language
can not find a char abbr of year, month, day.   y/m/d should be use.

>
> The actual age string is used in many places, including the page of life ({"name": "age", "value": "35y 4m 27d") that goes to the Thalamus and Federation, so we must be very careful with this.

Thalamus and Federation use unicode at the moment, so I think utf-8 is not problem

if thalamus and federation do not parse age info depend 'y' 'm' 'd' three string, I think no other problem :-)

>
> I like the idea of having the localized representation of years, months and days, but the original string should be the one that is stored.
>
> Another option is to use the date elements (year, month, day) within brackets. That will give us the possibility of using more than one char in the representation. Something like this:

seem to good idea, but I do not know how many code need to edit :-)

>
> 42[Y] 11[M] 9[D]
>
> The long repr should be valid too
> 42[Years] 11[Months] 9[Days]

I think long repr may be not a good idea, the reason:
1. it will use more space in view and report ...
2. it will break mamy (third part) packages depend on health
3. '42y 11m 9d' style work well in most situation, if a language support one char abbr of year, month, day, translation is good, if not, i think just use y,m,d.

 

>
> I have implemented the "raw_age" argument in the compute_age_from_dates method, that returns a list in the form [year, months, days]. We can probably play with this too.
>

seem to be a good idea, but many code need change :-)

>
> Finally, I started a while ago transitioning to f-string. I think is a great moment to do it on years_months_days var.
>
> PS.Check on the doc, the
>         ##   day   = split(' ')[1][:-1]
> Should be
>         ##   day   = split(' ')[2][:-1]

I will fix it.

>
> Let me know your thoughts and thank you for these great contributions!
>
> Bests
> Luis
>

comment #2:

> Hi, Feng
>
> I like the idea!
>
> There are some issues with this, since it's showing "h" for every element of the age.
>
> See the screenshot:
> https://imgur.com/J4QQSQJ.png
>

I'm curious where 'h' comes from.

Do you have run command: tryton-admin -u health -d <db>

> Let's move it as a task for 4.3 so we work on it and make sure that methods and objects that depend on the individual age are working properly with the change.
>
> PS: Don't forget to use a good description when creating or updating tasks and bugs :)

Fixed: https://hg.savannah.gnu.org/hgweb/health/rev/efab0e60f098