Closed Bug 928932 Opened 11 years ago Closed 10 years ago

Problem in Spanish translation for the word Birthday (Address Book | Contact | View)

Categories

(Mozilla Localizations :: es-ES / Spanish, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lapsap7+mz, Assigned: rpmdisguise-nave)

References

Details

This bug is created to separate the l10n problem from bug 928632.

I'm not Spanish speaker, so please forgive for my ignorance in advance.

Summary:
from bug 544315, it was stated that Birthday in English was incorrectly translated to "Cumpleaños" in Spanish while it should have been translated as "Fecha de nacimiento".

Please contribute your comments here (in Spanish) and try to come up with a consensus amongst Spanish users.  Please also take into account that
1. if the translation differs for countries, you have choices like
es-AR, es-CL, es-ES, and es-MX (as of 2013) to further separate this bug to match country

Please also change the summary to Spanish if that could help.

Hope this help
Blocks: 928632
(In reply to 石庭豐 (Seak, Teng-Fong) from comment #0)
> This bug is created to separate the l10n problem from bug 928632.
> 
> I'm not Spanish speaker, so please forgive for my ignorance in advance.
> 
> Summary:
> from bug 544315, it was stated that Birthday in English was incorrectly
> translated to "Cumpleaños" in Spanish while it should have been translated
> as "Fecha de nacimiento".
> 
> Please contribute your comments here (in Spanish) and try to come up with a
> consensus amongst Spanish users.  Please also take into account that
> 1. if the translation differs for countries, you have choices like
> es-AR, es-CL, es-ES, and es-MX (as of 2013) to further separate this bug to
> match country
> 
> Please also change the summary to Spanish if that could help.
> 
> Hope this help


I'd rather stick to English in BugZilla, to ease reviews. :-) If anyone needs any part translated to Spanish, just comment asking for it.

After reviewing the UI, it seems to me that the problem is UI or i18n related, not l10n related. Let me explain.

This is how Merriam Webster defines "birthday":

http://www.merriam-webster.com/dictionary/birthday

In English, "birthday" is used both to declare the specific day when someone was born (definition #1 in Merriam Webster's above URL), and to the day every year when the anniversary of that day is celebrated (definition #2). There is not a single word in Spanish that means both things at the same time; "cumpleaños" is the translation for definition #2, whereas "Fecha de nacimiento" is the translation for definition #1, at least in es-ES.

But the address book UI uses "birthday" with both meanings. The Edit card dialog, in its Private tab, displays this:

Birthday: [mm/dd][V] [Year] or [Age]

where [mm/dd][V] allows to enter a month and a day, with "[V]" representing a dropdown button that fires up a calendar datepicker. That calendar datepicker fills only month and day, even though it features the year.

If you fill in only the month and day, the address book displays like this:

Birthday: 12/25

which in Spanish reads as:

Cumpleaños: 25/12

which is perfectly fine (this contact celebrates his birthday every December 25th).

However, if you fill also the year or age, the address book displays like this:

Birthday: 12/25/1971

which in Spanish reads as:

Cumpleaños: 25/12/1971

which is wrong, as what you may expect to see after a "Cumpleaños" label is either a day and month (without a year reference), or the next full date when the birthday will be celebrated, for instance, 25/12/2013 (see this comment timestamp if you're reading in 2014). :-)

Possible solutions that come to my mind:

- Turn the year/age fields mandatory, so you always need to enter the birth date, and change the string so all localizations translate it with that meaning. But if is not so infrequent that you know when a contact celebrates his/her age but not the exact year when he/she was born (especially if it is "she"). ;-)

- Keep the Edit Contact dialog as it is now, but change the card display to something like this:

Birthday: MM/DD/<year of next birthday> (will reach: <age + 1> years)

with the parenthesis fragment being optional, displayed only when either year or age were filled.

This way, the term "birthday" will always refer to the day of each year when the contact celebrates being a new year older.
(In reply to Ricardo Palomares from comment #1)

Sorry, list of errata: 

> If you fill in only the month and day, the address book displays like this:
                                                                  ^^
                                                       this info for a given contact

> 
> Birthday: 12/25
> 
> which in Spanish reads as:
> 
> Cumpleaños: 25/12
> 
> which is perfectly fine (this contact celebrates his birthday every December
> 25th).
> 
> if you fill also the year or age, the address book displays like this:
                                                            ^^^
                                                 this info for a given contact


> (see this comment timestamp if you're reading in 2014). :-)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   adjust this date if you're reading this after Dec/26/2013


> Possible solutions that come to my mind:
> 
> - Turn the year/age fields mandatory, so you always need to enter the birth
> date, and change the string so all localizations translate it with that
> meaning. But if is not so infrequent that you know when a contact celebrates
               ^^
               it

Sorry for the mistakes.
(In reply to Ricardo Palomares from comment #1)
> After reviewing the UI, it seems to me that the problem is UI or i18n
> related, not l10n related.

If you want to turn this issue from l10n to UI/i18n, the fix will take longer to happen exactly because it is a fundamental change in UI.  (see comments below)


> Possible solutions that come to my mind:
> 
> - Turn the year/age fields mandatory, so you always need to enter the birth
> date, and change the string so all localizations translate it with that
> meaning. But if is not so infrequent that you know when a contact celebrates
> his/her age but not the exact year when he/she was born (especially if it is
> "she"). ;-)

Agreed with your last sentence. As a result, this solution/suggestion is not acceptable and/or feasible.
I also use Microsoft Outlook where I'm forced to input 1900 for those birthdays that I don't know the real year -- or any other arbitrary year less than 1940 to make sure it's not a real year because I have no friend other than that.  I am very delighted that Thunderbird allows us to omit the year. I do not like this to regress.


> - Keep the Edit Contact dialog as it is now, but change the card display to
> something like this:
> 
> Birthday: MM/DD/<year of next birthday> (will reach: <age + 1> years)
> 
> with the parenthesis fragment being optional, displayed only when either
> year or age were filled.
> 
> This way, the term "birthday" will always refer to the day of each year when
> the contact celebrates being a new year older.

How about changing the label to "Date of birth" as suggested by Mobius/Ian Neal?  And users are told that absence of year just simply implies absence of information.  Could this be more psychologically or linguistically acceptable?

My 2 cents as my last comment:
1. in French TB, the label is "Anniversaire" (the next event to celebrate in the future) but this doesn't seem to annoy them even though it should be "Date of birth" like in Spanish

2. I have never seen a change of label for birthday/date of birth in any other software (in French) because of presence or absence of year.
Take Google mail and Yahoo mail as example, what label is shown?  Does it change according to presence or absence of year?
[off-topic begins]
(In reply to Ricardo Palomares from comment #1)
> But the address book UI uses "birthday" with both meanings. The Edit card
> dialog, in its Private tab, displays this:
> 
> Birthday: [mm/dd][V] [Year] or [Age]
> 
> where [mm/dd][V] allows to enter a month and a day, with "[V]" representing
> a dropdown button that fires up a calendar datepicker. That calendar
> datepicker fills only month and day, even though it features the year.

This date-picker is actually quite buggy according to my personal standard. If the year is different from 2000, the year will be used. Or if you use it once again and pick 2000, it will fill 2000. Very unintuitive to use.

I would rather like a date-picker without year (and weekdays) -- that would be much more practical.
[off-topic ends]
(In reply to 石庭豐 (Seak, Teng-Fong) from comment #3)
> > - Keep the Edit Contact dialog as it is now, but change the card display to
> > something like this:
> > 
> > Birthday: MM/DD/<year of next birthday> (will reach: <age + 1> years)
> > 
> > with the parenthesis fragment being optional, displayed only when either
> > year or age were filled.
> > 
> > This way, the term "birthday" will always refer to the day of each year when
> > the contact celebrates being a new year older.
> 
> How about changing the label to "Date of birth" as suggested by Mobius/Ian
> Neal?  And users are told that absence of year just simply implies absence
> of information.  Could this be more psychologically or linguistically
> acceptable?


Yes, I think that would work.


> My 2 cents as my last comment:
> 1. in French TB, the label is "Anniversaire" (the next event to celebrate in
> the future) but this doesn't seem to annoy them even though it should be
> "Date of birth" like in Spanish


Honestly, it sounds a bit weird, but nobody should feel angry about it.


> 2. I have never seen a change of label for birthday/date of birth in any
> other software (in French) because of presence or absence of year.
> Take Google mail and Yahoo mail as example, what label is shown?  Does it
> change according to presence or absence of year?


In Spanish, the label does not change. But if you don't provide the year, the result is weird: for instance, "25/12/undefined".
Reversing the dependency. The L10n issue can only be solved once the patch in bug 928632 and its new strings land, not the reverse.
No longer blocks: 928632
Depends on: 928632
Fixed in central:

http://hg.mozilla.org/l10n-central/es-ES/rev/97541846eed6
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.