Closed Bug 458591 Opened 17 years ago Closed 5 years ago

Consider improving the labels on the Birthday Field

Categories

(MailNews Core :: Address Book, enhancement)

Product:
MailNews Core
Component:
Address Book
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: standard8, Unassigned)

References

(
URL
)

Details

Attachments

(2 files, 1 obsolete file)

TB-Abook-Bday-l10n-problem.png
18.16 KB, image/png
Details
Thunderbird - Address Book - Birthday field - Years old label (diff)
4.39 KB, patch
mconley
: feedback+
Details | Diff | Splinter Review
It was pointed out on my blog that the birthday field labels (for year/age) are a bit strange. When you haven't filled in anything, you get: Year or Age with the Year & Age being in the text boxes. This seems OK. When you fill in the year/date then you effectively get: 1964 or 44 This is a bit strange. Sounds like we don't know the year! We should consider maybe altering the labels when something is filled in, so you get: Year: 1964 Age: 44 or 1964 Age: 44 or 1964 ___ 44 Something like that, so that we avoid the "1964 or 44" situation. Bryan - Thoughts?
Hmm, yeah it's not the best after being filled in. Maybe we should drop the "or" after calculation? [ Year ] or [ Age ] [ Year ] [ Age ] We could even try to add in another label that explains better. Admittedly this gets difficult with translations. [ Year ] or [ Age ] [ Year ] [ Age ] years old
OS: Mac OS X → All
Hardware: PC → All
Switching the 'or' to 'Age: ' could work. I think most people should recognize birth years without a label, but maybe they would still want one.
So something like this? [ Year ], age: [ ]
Attached image birthday field in 5.0 (obsolete) —
this has been fixed see attached screenshot
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I'm using TB 24 but I still have the [ Year ] or [ Age ] on my screen. This bug doesn't seem fixed. Could someone confirm?
I have to reopen this bug because the labels are different in different language. I have tested German, French, English GB, English US and Chinese (Traditional), all in version 24, and only German and French have the correct label. In other words, this bug is not fixed for some languages. I'll upload an image later to show this problem. We have yet to determine what other languages are affected. OTOH, I have also tested in ver 3.0.11 in en-US and the label is also wrong. I think we can assume the label is wrong from ver 3 up to currently ver 24 for at least en-GB, en-US and zht. I hope once this bug is fixed, we could also have retrospective bug fix to all other old versions.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The label is correct only for certain languages.
Attachment #547165 - Attachment is obsolete: true
Thanks Magnus :) for showing us the source of the problem. By the way, is there a procedure to "trigger" requests to all L10N contributors to modify content of this label in all languages? Otherwise, here are the label contents for Chinese: Chinese (Traditional) zh-TW: "歲" Chinese (Simplified) zh-CN: "岁" Please add them.
Keywords: late-l10n
The way it's done (unfortunately) is we change the entity name (and update callers). E.g. YearsOld2.label "years old" Localizers pick it up once they notice the localization key changed. Fancy doing a patch?
Keywords: late-l10n
(In reply to Magnus Melin from comment #11) > The way it's done (unfortunately) is we change the entity name (and update > callers). E.g. > YearsOld2.label "years old" > > Localizers pick it up once they notice the localization key changed. I know you're serious but this way of doing is very bad. Do we really need to create a new label (entity name)? Imagine we do like this and "years old" would appear on en-US version. But the labels would disappear from other versions like French and German. This would be a regression more than a bug fix. > Fancy doing a patch? Sure, but only if I don't need to install a lot of things and compile source codes. I don't have time and computer for that purpose. Is there any quick start guide for patch?
Yes it's not a nice way, but that's what we have to do. Label's wont' disappear as all of this will have to "ride the trains", and would be available in the next release - and for that localizers have to update what's missing or there is no release for that localization. The minimum to create a patch is probably to install hg (mercurial) https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build https://developer.mozilla.org/en-US/docs/Developer_Guide
石庭豐: To make a patch, you don't need to compile anything, but you should download the appropriate source, and also keep it up to date to avoid bitrot. I strongly recommend activating the mq extension to Mercurial, at least in your Mozilla clones (you may have other Mercurial repositories): see "hg help extensions", and once enabled, "hg help mq". Other hg help subject will suggest themselves. IMHO it is better to use a separate "patch queue" for each bug you might be handling, see "hg help qqueue". You should of course type these "hg help" commands without quotes at what is called on Unix the shell prompt, or on Windows the command prompt. To _test_ your patch, you can either compile the source with your patch, or request that a "try build" be made, with your patch, on Mozilla build machines. When your patch is ready, request a try build in a comment, and someone (not me, I don't have the necessary privileges) will start the build.
Yesterday I spent about 30 min going through the "simple TB build" guide. Wow! That's long and I'm still at less than a half of the requirement. I then thought I'd try Tony's suggestion if that takes less time, or I'll just give up and leave the task to others who have more time. Anyway, it's hard to me find a decent computer to meet the hardware requirement because I use a simple notebook and mobile phone at home (ie after work). @Tony, I use SVN in my job but those "hg mq" or "hq queue" are a whole new language to me. I had spent another 30 min reading some mercurial tutorial yesterday but I still haven't gone up to any "mq" or "queue". Seems like I'll get back to this bug in the coming weekend if I have time. This bug was open on 2008 so I think it can wait :D But anyone who is used to the complex dev process of Mozilla is welcome to take the task :) OTOH, I was thinking about the correction. It seems to me that the problem lies in the incomplete l10n: en-US and en-GB being two of them. I have found this page: https://wiki.mozilla.org/L10n The page shows that they have l10n team and newsgroup and all that. So I think we could really save the existing label by just asking the l10n team to *fill the blank*.
(In reply to Magnus Melin from comment #9) > http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/ > messenger/addressbook/abCardOverlay.dtd#91 I have just found that there is another label of the same name at https://mxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/mailnews/addressbook/abCardOverlay.dtd#92
Code in /suite are for seamonkey, and /mail is for thunderbird. Shared stuff is in /mailnews. There's no localization team for en-US, that's just the default code. Blake: see any reason why we shouldn't show "years old" after the field in English?
Flags: needinfo?(bwinton)
I'm just used to CVS/SVN and the way of working and correcting codes in my company's software dev workflow. But if I need to get used to Mozilla's workflow, I think I'd need another 3 hours on reading. So let's do it quick: let me submit this diff first and let's see if it complies to your requirement. If it's not, just dump it. No problem. In reply to comment 17: then I'm not sure what "/messenger" stands for. Maybe it's in a dead branch? Anyway, my diff contains thing for it as well. NB: 1. I have not yet totally understood the "mq" extension so I have not installed it. 2. In order to use "try build", it seems like I need someone to "chaperon" me first. So, I have not tested the diff either as I have not yet finished the "build computer". (Off-topic: It would be nice if Mozilla could provide a build VM as a virtual appliance)
Nope, "years old" seems like a great idea to me. :)
Flags: needinfo?(bwinton)
Attachment #818393 - Flags: review?(mconley)
Hey! Thanks for the review request - I'll hopefully have time to look at this this weekend.
Comment on attachment 818393 [details] [diff] [review] Thunderbird - Address Book - Birthday field - Years old label (diff) Review of attachment 818393 [details] [diff] [review]: ----------------------------------------------------------------- I just wonder if perhaps the "years old" construct might require us to be a bit more flexible in terms of structuring for certain locales. See below. I'll needinfo? flod to get his opinion. ::: mail/locales/en-US/chrome/messenger/addressbook/abCardOverlay.dtd @@ +87,5 @@ > <!ENTITY In.label ""> > <!ENTITY Year.placeholder "Year"> > <!ENTITY Or.value "or"> > <!ENTITY Age.placeholder "Age"> > +<!ENTITY BDayYearsOld.label "years old"> <!-- Bug 458591 --> I don't think the comment listing the bug number is adding much - same below. I think they can be removed. ::: suite/mailnews/addrbook/abCardOverlay.xul @@ +258,5 @@ > placeholder="&Year.placeholder;" class="YearWidth" /> > <label control="Age" value="&Or.value;"/> > <textbox id="Age" maxlength="4" > placeholder="&Age.placeholder;" class="YearWidth" /> > + <label value="&BDayYearsOld.label;"/> Hm, I wonder... do we have to worry about locales where the "years old" might be ordered differently? For example, appearing before the text input, or on either side of it? It might be worth including another label before the textbox, just in case...
Comment on attachment 818393 [details] [diff] [review] Thunderbird - Address Book - Birthday field - Years old label (diff) feedback+ until I hear from flod.
Attachment #818393 - Flags: review?(mconley) → feedback+
Hey flod, Do you think for the "years old" construct we need to give localizers labels on either side of the text input?
Flags: needinfo?(francesco.lodolo)
Most locales don't have a concept of "years old" as a sort of adjective (we don't in Italian, Polish doesn't either), so most locales translated this label as "years", which is unclear (missing reference to "age"). A much solid solution would be "Age (in years): + [Number]", or "(age: XX)". But I have a lot more doubts about this part of UI: * why is this not a read-only element, since if I write something in it, it doesn't get stored? * the age calculation does funny things (you can get negative numbers based on the year, or have an age from year of birth "2e13")
Flags: needinfo?(francesco.lodolo)
It's more than a year and the bug is at a dead end. Oh how such situation is so familiar, esp in work: someone suggested something, then another one wants to make the idea better but what's secondly suggested is so complicated to implement that finally nothing is done! Before reaching the absolute perfection, could we just go one step first and then another after? Could we apply the patch and then think about a better implementation later?
"It's more than a year and the bug is at a dead end." The normal expectation is that you would have responded to comment 24 to move this bug forward. You did not, which is the "dead end". Can you update your patch to respond to the comments, or state why you cannot or don't want to?
I did not reply to comment 24?? Unless otherwise stated, that comment was in reply to comment 23 in which Mike addressed to flod. How in hell could I know he was asking me? OK OK, I'll reply to it later. I need to go.
Can we put a localization note in a .dtd file? Or we could put the string into a .properties file, have the string contain a placeholder, e.g.: "%y years old", then load the string via JS when the dialog is initialized, and insert the <textbox> element where the placeholder is. So not a plain GetFormattedString but similar.
(In reply to :aceman from comment #28) > Can we put a localization note in a .dtd file? Yes. I think the other option here is removing the editable age field. It could just be a changing label. How often do you really know someone's age exactly at a particular time of the year? Seems to me it's easier to just force people to enter a year (and show as a label of what age that would be).
Yeah, I have read bug 13595 where it was introduced. But I am not sure. Maybe it is just a convenience field for people who can't be bothered to compute "current year - age" to put into the year field?

This is quite different in 78, and not an issue I think. Basically what was suggested seem to be in place.

Status: REOPENED → RESOLVED
Closed: 15 years ago → 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: