bugGNU Health - Bugs: bug #64445, Make y,m,d of years_months_days...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #64445: Make y,m,d of years_months_days string returned by compute_age_from_dates translatable.

Submitter:  Feng Shu <tumashu>
Submitted:  Wed 19 Jul 2023 03:31:54 AM UTC
   
 
Category:  Functionality Severity:  1 - Wish
Item Group:  None Status:  Ready For Test
Privacy:  Public Assigned to:  tumashu
Open/Closed:  Open Release:  4.3.0
Module:  health Component:  Hospital Management

Jump to the original submission

Fri 21 Jul 2023 03:33:23 AM UTC, comment #9: 


comment #8:

>
> comment #7:
> >
> >     > 42[Y] 11[M] 9[D]
>
> looks good.


I have update the code, and find the result is not good, looks not beautiful, so I prefer zero widht space.

you can update to this changeset to test:

https://hg.savannah.gnu.org/hgweb/health/rev/dae8c77285e8


>
> >
> > 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.
>
>
> what about use "zero-width space"


New code use 'zero width space', seem to works well:

See https://hg.savannah.gnu.org/hgweb/health/rev/79ddda7c36c5


>
> >>> print('hello\u200bworld')
> hello​world
> >>> 'hello\u200bworld'.split('\u200b')
> ['hello', 'world']
>
>
> >
> > Question.. how about non-ascii chars, and non-latin representation? (like in the case of Chinese..) Can we represent it with a single char?
>
> Yes, Chinese only use a single char.
>
> year = 年 or 岁
> month = 月
> day = 日 or 天
>
>
> > Today we have the ascii-escaped representation, that would take more than one char.
>
> I think at the moment 'ascii-escaped' only exist in json string, we always load the json string, so it seem to no problem.
>
> >
> > We'll go back to the debate on ensure_ascii argument in json.dumps. Let's explore this more.
> >
> > Best
> > Luis
> > 
> >

Feng Shu <tumashu>
Group Member
Thu 20 Jul 2023 02:14:00 PM UTC, comment #8: 


comment #7:

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


looks good.

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



what about use "zero-width space"

>>> print('hello\u200bworld')

hello​world

>>> 'hello\u200bworld'.split('\u200b')

['hello', 'world']


>
> Question.. how about non-ascii chars, and non-latin representation? (like in the case of Chinese..) Can we represent it with a single char?


Yes, Chinese only use a single char.

year = 年 or 岁
month = 月
day = 日 or 天


> Today we have the ascii-escaped representation, that would take more than one char.


I think at the moment 'ascii-escaped' only exist in json string, we always load the json string, so it seem to no problem.

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

>

Feng Shu <tumashu>
Group Member
Thu 20 Jul 2023 12:23:58 PM UTC, comment #7: 


    > 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
 

Luis Falcon <meanmicio>
Group administrator
Thu 20 Jul 2023 02:22:45 AM UTC, comment #6: 
Feng Shu <tumashu>
Group Member
Thu 20 Jul 2023 12:26:26 AM UTC, comment #5: 


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
>

Feng Shu <tumashu>
Group Member
Wed 19 Jul 2023 05:33:44 PM UTC, comment #4: 

I did update the DB but with health_gyneco from last refresh. Funny the "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.

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.

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:

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

The long repr should be valid too
42[Years] 11[Months] 9[Days]

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.


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]

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

Bests
Luis

Luis Falcon <meanmicio>
Group administrator
Wed 19 Jul 2023 10:01:20 AM UTC, comment #3: 


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 :)

Feng Shu <tumashu>
Group Member
Wed 19 Jul 2023 09:43:06 AM UTC, 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

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 :)

Luis Falcon <meanmicio>
Group administrator
Wed 19 Jul 2023 03:32:29 AM UTC, comment #1: 
Feng Shu <tumashu>
Group Member
Wed 19 Jul 2023 03:31:54 AM UTC, original submission:  


Feng Shu <tumashu>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by meanmicio (Posted a comment)
  • -email is unavailable- added by tumashu (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-02 tumashu StatusNeed Info Ready For Test
    2023-07-19 meanmicio Severity3 - Normal 1 - Wish
        StatusReady For Test Need Info
    2023-07-19 meanmicio CategoryNone Functionality
        Assigned toNone tumashu
        ReleaseNone 4.3.0
    2023-07-19 tumashu StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code