215431 - Unlocalizeable strings

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Pavel Cvrcek (inactive account - please use [e-mail])]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; cs-CZ; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Win98; cs-CZ; rv:1.4) Gecko/20030612

Mozilla Calendar 2003080411-cal (Windows)


file: eventDialog.js
================================================
function getWeekNumberText( weekNumber )
{
   switch( weekNumber )
   {
   case 1:
      return( "First" );
   case 2:
      return( "Second" );
   case 3:
      return( "Third" );
   case 4:
      return( "Fourth" );
   case 5:
      return( "Last" );
   default:
      return( false );
   }

}

- It cannot be localized.
================================================

file: eventDialog.js
================================================
function getDayExtension( dayNumber )
{
   switch( dayNumber )
   {
      case 1:
      case 21:
      case 31:
         return( "st" );
      case 2:
      case 22:
         return( "nd" );
      case 3:
      case 23:
         return( "rd" );
      default:
         return( "th" );
   }
}

- It cannot be localized.
================================================

file: calendarMail.js
================================================

var rv = confirm( "You do not have a default email account setup. Click OK and
the Account Wizard will be started, otherwise click Cancel." );

- It cannot be localized.
================================================

file: calendar.js
================================================

if( confirm( "Are you sure you want to delete all selected events?" ) )

- It cannot be localized.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mike Loll]

Ok, I have some ideas on how to fix these localization problems.

For the first issue, I could add an entry to the dateFormat.properties file
under the localization directory (I could do it for en-US, others would have to
do it for their own language) that would add a new property like so:

week.1.ordinal.name=First
week.2.ordinal.name=Second
week.3.ordinal.name=Third
week.4.ordinal.name=Fourth
week.5.ordinal.name=Fifth

etc for 52 weeks and also put in

week.last.ordinal.name=Last

Then rewrite the SWITCH statement accordingly.  Of course, this would require
that these additions be made to all other localization.s

For the second issue, I would do a similar thing like so:

day.1.ordinal.suffix=st
day.2.ordinal.suffix=nd
day.3.ordinal.suffix=rd

etc up to 31.  I would modify the switch statement accordingly.

For the remaining two issues, I could add an entry to the calendar.properties
file in en-US to have strings for these dialogs.

Of course, all of these changes would make a change needed in any localization
to take advantage of it.

Am I thinking in the right direction?

Comment 2

[Eric Belhaire]

Mike: Yes you are in the right direction. 
Nevertheless, it seems that a more in deep (but simple) rewriting could be
better. The getWeekNumberText is now used to build sentences at lines 1255, 1263
and 1269 of eventDialog.js. The formatting of the sentence is for exemple :
      getWeekNumberText( weekNumber )+" "+getDayOfWeek( dayNumber
)+document.getElementById( "ofthemonth-text" ).getAttribute( "value" )

This formatting of the sentence is not localizable. I mean that the order of the
words is then hardcoding. I am not really sure that this way to do can be
adapted to all languages. In fact, it is possible to localize the formatting
also. You can look at the string "TooManyAlarmsMessage" in calendar.properties
for an exemple of a formatted string. It is used in alertDialog.js with the
function getFormattedString();

It is true that a change will be needed in any localization file, but it is not
a problem. Modify it in en-US and your own language to begin with, the changes
will be reported in the other localization files directly by Mostafa after CVS
checkup.

Comment 3

[Mike Loll]

Eric:

So I first need to localize the functions so that they returned localized
strings.  Then I need to localize the sentence structure any where those
functions are used, correct?

Comment 4

[Mike Loll]

Sorry to keep posting here, but I just want to verify things.  Also, if
questions such as these pertaining to the bug are better for the newsgroup,
please let me know.  I don't want to clog up bugzilla.

There are date localizations present in the dateFormat.properties and global.dtd
files that overlap.  Now, I understand that the DTD file (and its entities) are
for use in the XUL files, and subsequently can be used in the corresponding JS
file as well.

Now, the dateFormat.properties file is also used within eventDialog.js.  Which
file should I put my localizations in for this bug?  It seems like effort is
being duplicated here by having both files.  Unless we are concerned about file
sizes by loading a bigger DTD file into eventDialog.xul.

I plan on putting my localized sentence in calendar.properties, but should I put
my localized dates in global.dtd or dateFormat.properties.  They will only be
used in eventDialog.js, so I suspect I should put them in the
dateFormat.properties file.  But I am not sure.

Comment 5

[Eric Belhaire]

Mike:
>So I first need to localize the functions so that they returned localized
>strings.  Then I need to localize the sentence structure any where those
> functions are used, correct?
Correct, I think (after a quick (really quick) check.

I don't know the better place in fact for your localization strings. It seems
that after a lot of iteration in the calendar code, the localization logic is
lost. Even if I like xxx.dtd files because its coding is UTF-8 and more common
in editors, the properties files (in escaped-unicode) are the right choice for
JS strings. They allow an easy implementation of formatted strings. So, to
conclude it would be OK for you to use :
- calendar.properties for your localized sentence
- dateFormat.properties for your localized dates

Comment 6

[Mike Loll]

Attachment: Patch for localization problems.

Well, here is a proposed patch for the problem.  It modifies a few files in
Calendar, both locale files and xul/js files.  Please check it out.  Please
check that I am not doing things "the long way".  If there is a faster, better
way, please let me know.

Comment 7

[Mostafa Hosseini]

Attachment: Tweaked previous patch

Thanks a lot for the patch. I personally learned a lot from it.
Now, I have a few suggestions which I will provide a new patch for:

1) Make the ordinal name and suffixes more general by removing the "day." and
"week." from their name: ( e.g. week.1.ordinal.name -> ordinal.name.1 ) so that
they can be used in other cases.

2) Fifth week is never used. When the selected day is on the fifth week, the
code considers it to be the "last".( Hence the change to getWeekNumberText )

If you agree with these changes please obsolete the previous patch so I could
proceed and apply the same change to the ToDo dialog.

Comment 8

[Mostafa Hosseini]

Ccing [e-mail] for his feedback.

Comment 9

[Mike Loll]

Comment on attachment 136577 [details] [diff] [review]
Patch for localization problems.

Per Mostafa's request, I've obsoleted the first patch.	The changes as
described by Mostafa look good to me.

Comment 10

[Mostafa Hosseini]

Patch checked in, as well as same changes to todoDialog.* and other language files.

Comment 11

[Joey Minta]

As best I can tell, this issue has been resolved.  The CalendarMail.js string
still remains present, but the file itself hasn't even been touched for nearly a
year.  Is there a reason to keep this bug open?

Comment 12

[Joey Minta]

l10n has come a long way since this bug, and as said in comment #11, nearly all
of the problems pointed out have been solved.  The final remaining string
doesn't seem to ever be displayed for the user.  In light of the fact that a
patch was checked in, marking fixed.

Comment 13

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Sunbird Only. Be afraid for your sanity!