[i18n] Add properties file for address book for strings in js

VERIFIED FIXED in M17

Status

defect
P3
normal
VERIFIED FIXED
20 years ago
15 years ago

People

(Reporter: chjung, Assigned: alecf)

Tracking

Trunk
x86
Other
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

Attachments

(1 attachment)

Tasks->Addressbook->New Card
Title of the form "New Card for" can't be localized.
Changing summary to reflect the need to add the properties file to address book.  
There are at least four strings in the js file that need to move to properties.
Status: NEW → ASSIGNED
Summary: Strings missing in addressbook .dtd and .properties files → Add properties file for address book for strings in js
Target Milestone: M16
Blocks: 27779
Not M16 stopper.  Moving to M17.  Please add keyword beta2 if this is a beta2 
blocker.
Target Milestone: M16 → M17
I can't repro this.  Has this already been fixed?

Adding msanz to cclist.
This seems to be a trivial fix. Could we get this done in M16 so deveopers can
focus on beta-2 stoppers later?


Thanks
Mass move mailnews bugs to Putterman.  Ouch.
Assignee: hangas → putterman
Status: ASSIGNED → NEW
I believe this has been fixed. Can someone verify this? 
The string "New Card for " is in abCardOverlay.js only.
You can localize it but this is not the right place to 
do it. Someone should look into extracting this out
of the file somehow. The string name is: editCard.newCardTitlePrefix

Thefore, not fixed yet.
Changed QA contact.
QA Contact: lchiang → momoi
Kat, you are right. The string will replace "New Card" from DTD. 

I add nsbeta2 keyword and reassign it to hangas.
Assignee: putterman → hangas
Keywords: nsbeta2
I'm the ab owner now. reassigning back to me.
Assignee: hangas → putterman
reassigning to alecf.
Assignee: putterman → alecf
Status: NEW → ASSIGNED
Summary: Add properties file for address book for strings in js → [i18n] Add properties file for address book for strings in js
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
fix is in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
fix is in
Resolution: FIXED → ---
argh, mid-air collision with myself
Status: RESOLVED → REOPENED
fix is in
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
** Checked with 5/30/2000 Win32 build **

I don't think the fix is complete. Looking at the changes made,
at minimum, "newCardTitlePrefix" will have to be referenced
in "addressbook.properties" for this to work. There are
also a few more that need to be extracted.
Looking in the addressbook.properties file, I don't see these
variable defined. Here are some of the problems observed
in creating a new card due to the lack of definitions.

1. When creating a new Card, "New Card for" is not dynamically
   shown in the Window title as you begin inputting. Instead,
   you see the title "undefined".
2. When an entry is finished, and when you select that entry
   in the view window of Address Book, heading such as
"Display Name:" shows up as "undefined".

Problem #2 occurs even if you supply:

newCardTitlePrefix=New Card for

in the addressbook.properties

There is another problem I've observed, probably not related to this
problem but,

3. The first time you try entering Name into First Name field,
   Auto-Generation does not seem to start at all -- thus you don't
   see the "New Card" change into "New Card for ..." dynamically.
   This seems to start working the 2nd time you try it.

The 4th problem is something sorely needed when constructing a string
like this one:

top.window.title = editCard.titlePrefix + editCard.card.displayName;

This line seems to fix the order of these items to English 
Syntax. For Japanese, as an example, we need to reverse
this order. For example, "New Card for Alec" in Japanese would
correspond to "Alec's New Card".
Can you extract not just "editCard.titlePrefix" but rather
the whole string? 

Re-opening for the above reasons.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
oh no! I think I forgot to check in the properties file....yep, sure enough I 
did. I'll check it in when the tree "opens" and re-mark this fixed.
Status: REOPENED → ASSIGNED
OS: Windows 98 → other
ok, fix went in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
** Checked with 6/2/2000 Win32 build **

I'm re-opening this because the issue I rasied in #4 was not
addressed. See, for example:

newCardTitlePrefix=New card for
editCardTitlePrefix=Card for

Please do it in such a way so that the name of the person
can come before this phrase. So, something like:

newCardTitle=New card for %s
editCardTitle=Card for %s

For Japanese, we would change the order to:

newCardTitle=  %s's New card
editCardTitle=  %'s Card

I translated these entities into Japanese as they are,
and sure enough it did not come out as Japanese at all.
We need this syntactic flexibility to allow for different
word orders among languages.


Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ok... in order to do that I need to have nsTextFormatter::smprintf visible from 
JS, which I was actually working on.

The attached patch adds formatStringFromName to the string bundle API so that 
one can create localized strings...I have a bunch of other bugs where this is 
useful

Kat or Tao, do you mind reviewing?
Status: REOPENED → ASSIGNED
Looks good. Comments:

1. Thanks for cleanin up the code (nsString->nsAutostring, etc...
2. Would you provide a brief explanation of usage so people know how to use it.


Thanks
thanks tao, fix is in for that part. now I'll just use formatted strings for
this bug and we'll be all set!
ok, the formatting strings are being used now
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
** Checked with 7/6/2000 Win32 build **

Both "New Card for..." and "Card for ..." now can be localized.
I looked the above build and the first localized build based on 
M17 built on 6/26/2000. 
Within the Address Book card, this is working but as mentioned
in Bug 39576, I noticed that in the view pane for a card on
the right side of Address Book, the English "Card for .." still 
appears even after "editCardTitle" has been localized.

cvPrefs.titlePrefix is what corresonds to this part
and is mentioned as coming from "addressboook.js".

In any case, it does look odd that within the card, the same
item is localized but in the viewing pane, it is not.

I'm giong to mark this fix verified but will mention the
localizability problem for "Card for" in the other bug.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.