160601 - Localizability for address book UI, order of fields in "Address" panel / print-preview & print

Status: NEW

(MailNews Core :: Address Book, defect)

Description

[nhottanscp]

The current order, street, city, state does not apply to some countries.
We need a way to localize the order. Also probably need a way to adjust width of
the fields (e.g. state/province field may need more than two characters).

Comment 1

[nhottanscp]

Reassign to nhotta, cc to l10n.

Comment 2

[ji]

Nominating.

Comment 3

[Samir Gehani]

adt: nsbeta1-

Comment 4

[Robert Kaiser]

zip code counts in here as well...

Comment 5

[Robert Kaiser]

*** Bug 204179 has been marked as a duplicate of this bug. ***

Comment 6

[Simon Montagu :smontagu]

*** Bug 194264 has been marked as a duplicate of this bug. ***

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I discussed this with Asai-san who is JP localizer.
We need to fix for jp marketing.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv1.0

Scott:

This patch fixes this bug. But this patch adds many files and overlays. I don't know this is best way. But I don't have other ideas...

Comment 9

[Scott MacGregor]

Masayuki, can you go into more detail about what we want to change? Do we just want to come up with a way to change the order of the various fields in an address book card? 

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #9)
> Masayuki, can you go into more detail about what we want to change? Do we just
> want to come up with a way to change the order of the various fields in an
> address book card? 
> 

Scott, sorry for the delay. We need to customize the order of address book card items for each countries.

I think that the items should be customizable in each groups on 'Contact' and 'Address' tabs. And 'State/Province' and 'ZIP/Postal Code' should be swappable.

If you have better idea for implement this function, we should use it.
# I don't have better idea, now.

Comment 11

[Scott MacGregor]

Alternatively, couldn't we just manipulate the DOM before we show the address book card? Have a localizeable property which specifies the desired order. Then in JS manipulate the dom to re-order the properties? That might be simpler than this approach.

Mark, do you have any thoughts here?

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #11)
> Alternatively, couldn't we just manipulate the DOM before we show the address
> book card? Have a localizeable property which specifies the desired order. Then
> in JS manipulate the dom to re-order the properties? That might be simpler than
> this approach.
> 
> Mark, do you have any thoughts here?

Right, it's simple. But I have no idea for specifying the order, I'm thinking that.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv2.0

Sorry, for the delay. I changed from the overlay hack to DOM hack.
Please check this.

# This patch doesn't change the card viewer of 'Address Book' window.
# We should separate to new bug after this.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv2.1

fix typo.

Comment 15

[Mark Banner (:standard8)]

Neil, any chance you could have a look at this from the DOM hack aspect?

Comment 16

[Mark Banner (:standard8)]

Comment on attachment 221976 [details] [diff] [review]
Patch rv2.1

Masayuki, thanks for the patch. Sorry for not looking earlier. I've asked Neil to have a look at the DOM re-ordering aspect as he's more experienced in that area than I am.

To me though, this approach definitely looks simpler that the overlays patch. If Neil can't think of a better way, then I'll be happy with it.

Just some comments though whilst I'm here:

When I tried it I was getting an error loading the card dialog:

failed to get group container of Name
failed to get group container of Internet
failed to get group container of Phone
failed to get group container of Home
failed to get group container of Work
JavaScript error: chrome://messenger/content/addressbook/abCardOverlay.js, line 449: doc.getElementById(kVcardFields[i][0]) has no properties

Hence I couldn't actually test it. Any ideas, or do I need to look deeper at my end?

+#ifdef MOZ_THUNDERBIRD

Any chance you could the equivalent patch for SeaMonkey please? I'd like to keep the two in sync, especially with such a big and useful a change as this.

RCS file: mail/components/addrbook/content/abEditCardOverlay.xul
diff -N mail/components/addrbook/content/abEditCardOverlay.xul
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ mail/components/addrbook/content/abEditCardOverlay.xul	14 May 2006 16:50:30 -0000

Could you call the new overlay abCardOverlay.xul ? Firstly, it'll match the js, and secondly it'll match SeaMonkey's version which will be useful when trying to remember where things are.

Thanks.

Comment 17

[Mark Banner (:standard8)]

(In reply to comment #13)
> # This patch doesn't change the card viewer of 'Address Book' window.
> # We should separate to new bug after this.

Before I forget, if you look at doing this, I think we need to look at how the preview is generated in itself. Possibly using a browser element rather than whatever it is at the moment, so that the format is more easily controlled and it could fix other problems such as text selection. Might be worth taking the discussion for those ideas onto m.d.a.thunderbird/m.d.a.seamonkey. Additionally we also need to think about printing formats.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv2.2

Mark:

Sorry, I forgot to include jm file. Please retest with this patch.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Mark:

> Any chance you could the equivalent patch for SeaMonkey please? I'd like to
> keep the two in sync, especially with such a big and useful a change as this.

Of course, if this is finished, I'll work for SeaMonkey. But I don't want to write same code twice in this time. But after this fixed, I will need to write only once for SeaMonkey :-)

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

the card viewer:
http://lxr.mozilla.org/mozilla/source/mail/components/addrbook/content/addressbook.xul

I think that print is using this too.

Comment 21

[Mark Banner (:standard8)]

(In reply to comment #18)
> Sorry, I forgot to include jm file. Please retest with this patch.
> 

I realised that about 5 mins after comment on the bug. Anyway, the new patch works.

What I don't understand at this stage is the need to be able to re-order the email and phone items.

Once Neil has commented on the DOM aspects I'll review the patch in full.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #21)
> What I don't understand at this stage is the need to be able to re-order the
> email and phone items.

Everyone don't know *all* major address card format on every countries and areas. Of course, it's including unknown countries and areas by current l10n team.
We should provide localizability for *all* countries and areas.

Comment 23

[[e-mail]]

Comment on attachment 221978 [details] [diff] [review]
Patch rv2.2

>+          <vbox id="NameItems">
>+            <hbox id="NameItem_FirstName">
>...
>+            <hbox id="NameItem_LastName">
>...
>+            <hbox id="NameItem_DisplayName">
>...
>+            <hbox id="NameItem_NickName">
>...
>+          </vbox>
For what you are trying to do, I think that there is a simpler solution.
XUL has an attribute "ordinal" which changes the order that elements appear on the screen but without actually modifying the DOM. So, you could write:

<vbox id="NameItems">
  <hbox ordinal="&FirstName.ordinal;"> ... </hbox>
  <hbox ordinal="&LastName.ordinal;"> ... </hbox>
  <hbox ordinal="&DisplayName.ordinal;"> ... </hbox>
  <hbox ordinal="&NickName.ordinal;"> ... </hbox>
</vbox>
You would then give these entity values 1 to 4 in the en-US locale.

Note: use document.commandDispatcher.advanceFocusIntoSubtree to select the first (by ordinal) focusable element in a box.

Comment 24

[Mark Banner (:standard8)]

(In reply to comment #22)
> (In reply to comment #21)
> > What I don't understand at this stage is the need to be able to re-order the
> > email and phone items.
> Everyone don't know *all* major address card format on every countries and
> areas. Of course, it's including unknown countries and areas by current l10n
> team.
> We should provide localizability for *all* countries and areas.

I quite agree with providing localizability for all areas, but I still don't see the need. For instance, why would secondary email, screenname or compose as preference need to be above primary email? The only thing I can think of is if a page is read from bottom to top, and as far as I'm aware, there are no languages that do that (please correct me if I'm wrong).

A similar issue is with the phone numbers, I can't see why a fax number would *have* to appear before a home number in a different country?

I'm not against providing flexibility, but at the moment I don't see a good reason. I'm concerned that it may cause confusion and bloat if we provide too much flexibility with no good reason.

Comment 25

[Mark Banner (:standard8)]

Comment on attachment 221978 [details] [diff] [review]
Patch rv2.2

Please can you try Neil's suggestion for the reordering, and I also still think that email & phone shouldn't need to be touched.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch rv3.0

This patch uese 'ordinal' attribute. This is very simple, thank you Neil for your suggestion.

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #25)
> (From update of attachment 221978 [details] [diff] [review] [edit])
> Please can you try Neil's suggestion for the reordering, and I also still think
> that email & phone shouldn't need to be touched.
> 

Mark:
Sorry for the delay. I was working on Gfx issue on cairo.

I can understand your question. But I cannot think that the non-flexible is better than flexible for localizers(not users).

I'm not a member of Japanese localizer team. Therefore, following examples may not be used on ja-JP build. Please be careful it.

In Japan, the pager isn't used on Japan. Because the pager service will be finished by 2007-03-31. But mobile phone service is very popular, maybe it is more than home telephone for young people. I think that the Phones group current order is not matching to the current state in Japan.

And in Japan, in many cases, the name gets first position. So, the Internet group's Screen Name should be first position in Japan.

I don't know the ja-JP localizer group hope to change these group's order. But we should keep localizability, I think.

Comment 28

[Mark Banner (:standard8)]

Comment on attachment 222868 [details] [diff] [review]
Patch rv3.0

Index: mail/components/addrbook/content/abEditCardOverlay.xul
===================================================================
RCS file: mail/components/addrbook/content/abEditCardOverlay.xul
diff -N mail/components/addrbook/content/abEditCardOverlay.xul
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ mail/components/addrbook/content/abEditCardOverlay.xul	22 May 2006 15:40:08 -0000
@@ -0,0 +1,367 @@
+<?xml version="1.0"?> 
+# ***** BEGIN LICENSE BLOCK *****
+# Version: MPL 1.1/GPL 2.0/LGPL 2.1

Scott, assuming you're happy with New & Edit card dialogs sharing an overlay rather than defining the same data twice. How about putting this overlay in mailnews/addrbook/resources/content and sharing it between SeaMonkey & Thunderbird hence saving more time when we get round to adding new fields later?

Comment 29

[Scott MacGregor]

(In reply to comment #28)
> (From update of attachment 222868 [details] [diff] [review] [edit])
> Index: mail/components/addrbook/content/abEditCardOverlay.xul
> ===================================================================
> RCS file: mail/components/addrbook/content/abEditCardOverlay.xul
> diff -N mail/components/addrbook/content/abEditCardOverlay.xul
> --- /dev/null   1 Jan 1970 00:00:00 -0000
> +++ mail/components/addrbook/content/abEditCardOverlay.xul      22 May 2006
> 15:40:08 -0000
> @@ -0,0 +1,367 @@
> +<?xml version="1.0"?> 
> +# ***** BEGIN LICENSE BLOCK *****
> +# Version: MPL 1.1/GPL 2.0/LGPL 2.1
> 
> Scott, assuming you're happy with New & Edit card dialogs sharing an overlay
> rather than defining the same data twice. How about putting this overlay in
> mailnews/addrbook/resources/content and sharing it between SeaMonkey &
> Thunderbird hence saving more time when we get round to adding new fields
> later?

That sounds like a great idea!

Comment 30

[Mark Banner (:standard8)]

Masayuki, before you address the moving of the file, I'll try and get round to reviewing this before the end of the weekend.

Comment 31

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #30)
> Masayuki, before you address the moving of the file, I'll try and get round to
> reviewing this before the end of the weekend.
> 

O.K. regards.

Comment 32

[u60234]

Is there a strong technical reason for coupling the State/Province and ZIP/Postal Code together like that? It is not really suitable for Swedish addresses where the typical form is street, postal code, city.

Comment 33

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #32)
> Is there a strong technical reason for coupling the State/Province and
> ZIP/Postal Code together like that? It is not really suitable for Swedish
> addresses where the typical form is street, postal code, city.

How should it be concretely?

Comment 34

[u60234]

For sv-SE, I would prefer to either have all text boxes lined up vertically and being able to customize the order like this:
Address
Postal Code
City

or better yet, be able to put the text boxes for Postal Code and City in the same hbox:
Address
Postal Code    City

Comment 35

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I see. But I think that the issue is not a scope of this bug.
I think that you should file a new bug for it after this is fixed.

Comment 36

[Axel Hecht [:Pike]]

(In reply to comment #27)

> I can understand your question. But I cannot think that the non-flexible is
> better than flexible for localizers(not users).

Any complexity that is not required is just a cause of bugs. Any of those numbers
can have arbitrary values, or be transcoded into a local number system or 
whatever.

Make sure that the localization note is *VERY* verbose on which entities are 
allowed which values. If it's too tricky to document in the code itself,
create a page on devmo and link to it.

Comment 37

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #36)
> (In reply to comment #27)
> 
> > I can understand your question. But I cannot think that the non-flexible is
> > better than flexible for localizers(not users).
> 
> Any complexity that is not required is just a cause of bugs. Any of those
> numbers
> can have arbitrary values, or be transcoded into a local number system or 
> whatever.
> 
> Make sure that the localization note is *VERY* verbose on which entities are 
> allowed which values. If it's too tricky to document in the code itself,
> create a page on devmo and link to it.

Axel, that is not about the way of flexibility. We were talking about what items should be flexible.

Comment 38

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Mark:

We don't have much time for this bug. We should fix this before 2.0b1 that freezes the localization. Please hurry up to review. Note that I'll be offline between 6/5 to 6/7 in JST.

Comment 39

[Mark Banner (:standard8)]

Comment on attachment 222868 [details] [diff] [review]
Patch rv3.0

Sorry for the delay, I've been asking a few questions. I've not tested this yet on my builds as they are currently rebuilding. However, here are my comments:

+  setTimeout( setFirstFocusableElement, 0, "NameItems" );
+
   moveToAlertPosition();
 }
 
+function setFirstFocusableElement(elementId) {
+  var nameGroup = document.getElementById(elementId);

I don't think you need to pass the elementId into the function here as its the only place you are using it.

-    // XXX Using the setTimeout hack until bug 103197 is fixed

Please also leave this in, its there for a reason and you're not fixing that bug here.

--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ mail/components/addrbook/content/abEditCardOverlay.xul	22 May 2006 15:40:08 -0000

Please make the relevant changes to mailnews/addrbook/resources/content/abCardOverlay.xul instead of this file. This will mean we can reuse code, as Scott agreed to earlier on this bug. If you're careful I think you can keep the licence and copy everything else across. Though you should check the diffs before and after. It should also make the patch simpler to review ;-)

abCardOverlay.xul is already included in Thunderbird's jars, so you should be ok there.

However, it will require you to do the SeaMonkey changes at the same time, but they should be a lot less now.

+  <stringbundleset id="stringbundleset">
+    <stringbundle id="bundle_addressBook" src="chrome://messenger/locale/addressbook/addressBook.properties"/>
+  </stringbundleset>
+
+  <!-- move needed functions into a single js file -->
+  <script type="application/x-javascript" src="chrome://messenger/content/addressbook/abCommon.js"/>
+  <script type="application/x-javascript" src="chrome://messenger/content/addressbook/abCardOverlay.js"/>

Please check the inclusion of those lines in the various xul files. Basically we don't want to have duplicates caused by two overlays including them as it will increase processing time. Its probably possible to keep them in the abCardOverlay.xul and remove them from the Edit & New card xul files (as per SeaMonkey's current implementation).

+<!ENTITY PrimaryEmail.ordinal           "1">
+<!ENTITY SecondEmail.ordinal            "2">
+<!ENTITY PreferMailFormatPopup.ordinal  "3">
+<!ENTITY ScreenName.ordinal             "4">

I'm not happy with being able to re-order these fields. I don't think its a localization requirement and no one (I checked on l10n newsgroup as well) has given me a really good reason.

The phone numbers I think we can go with.

+<!-- LOCALIZATION NOTE :
+     You can specify that the order of the items on each groups -->

This needs to be clearer to state that only numerical characters are allowed and they don't get translated.

+            <hbox ordinal="&HomeStateAndZipCode.ordinal;">
+              <spacer flex="1"/>
+              <label control="Home&StateAndZipCodeLeft.id;" value="&HomeStateAndZipCodeLeft.label;" class="CardEditLabel"/>
+              <hbox class="CardEditWidth">
+                <textbox id="Home&StateAndZipCodeLeft.id;" flex="1"/>
+                <spacer class="stateZipSpacer"/>
+                <label control="Home&StateAndZipCodeRight.id;" value="&HomeStateAndZipCodeRight.label;" class="CardEditLabel"/>
+                <textbox id="Home&StateAndZipCodeRight.id;" flex="1"/>
+              </hbox>

Did you try a second level of ordinals here? I think you may be able to do it inside the hbox. You may need to break it up into vbox elements.

We believe the way you have the id (defined from the entity) is invalid when compared against the XML 1.0 specification. See here: http://www.w3.org/TR/REC-xml/#sec-attribute-types

specifically where it says

"Values of type ID MUST match the Name production."

Name is defined as 

Name	   ::=   	(Letter | '_' | ':') (NameChar)*

Apologies for the random order of comments, I had to flick back and forth several times.

Comment 40

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you for the review.

(In reply to comment #39)
> +            <hbox ordinal="&HomeStateAndZipCode.ordinal;">
> +              <spacer flex="1"/>
> +              <label control="Home&StateAndZipCodeLeft.id;"
> value="&HomeStateAndZipCodeLeft.label;" class="CardEditLabel"/>
> +              <hbox class="CardEditWidth">
> +                <textbox id="Home&StateAndZipCodeLeft.id;" flex="1"/>
> +                <spacer class="stateZipSpacer"/>
> +                <label control="Home&StateAndZipCodeRight.id;"
> value="&HomeStateAndZipCodeRight.label;" class="CardEditLabel"/>
> +                <textbox id="Home&StateAndZipCodeRight.id;" flex="1"/>
> +              </hbox>
> 
> Did you try a second level of ordinals here? I think you may be able to do it
> inside the hbox. You may need to break it up into vbox elements.

The two items are not same structure. We cannot use ordinals simply. Do you have an idea?

> We believe the way you have the id (defined from the entity) is invalid when
> compared against the XML 1.0 specification. See here:
> http://www.w3.org/TR/REC-xml/#sec-attribute-types
> 
> specifically where it says
> 
> "Values of type ID MUST match the Name production."
> 
> Name is defined as 
> 
> Name       ::=          (Letter | '_' | ':') (NameChar)*
> 
> Apologies for the random order of comments, I had to flick back and forth
> several times.

really? the note said:

> The Names and Nmtokens productions are used to define the validity of tokenized attribute values after normalization (see 3.3.1 Attribute Types).

The 'normalization' doesn't include the replacing the entities?

Comment 41

[Mark Banner (:standard8)]

(In reply to comment #40)
> Thank you for the review.
> The two items are not same structure. We cannot use ordinals simply. Do you
> have an idea?

Ah, sorry I hadn't noticed that when I first read it.

> really? the note said:
> 
> > The Names and Nmtokens productions are used to define the validity of tokenized attribute values after normalization (see 3.3.1 Attribute Types).
> 
> The 'normalization' doesn't include the replacing the entities?
> 
Ok, I've taken another look and it looks like you are right, however I've also posted a message on mozilla.dev.tech.xml asking someone to confirm just to make sure.

In which case:

+<!-- LOCALIZATION NOTE : DONT_TRANSLATE
+     You can specify that the 'State/Province' and
+     'ZIP/Postal Code' should be swapped, or not. -->
+<!ENTITY StateAndZipCodeLeft.id         "State">
+<!ENTITY StateAndZipCodeRight.id        "ZipCode">

Please extend this note to state that "State" and "ZipCode" are the only allowable values and shouldn't be localized.


I'd also think about if its worth putting the all the state and zip items together within the dtd so its more obvious that they are all linked. This last item is not necessary for an r+ from me though.

Comment 42

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #41)
thanks.

I'm working on this in high priority. But next patch comes tomorrow.

Comment 43

[Axel Hecht [:Pike]]

Reading through the bug, I come to the conclusion that this needs a documentation
page, which should include sample orderings for the english strings and screen
shots.

Living in a domain where US address notations make hardly any sense myself, I 
see only limited value of over-engineering this, and if we have to, I don't
see people understanding what they're supposed to do without having a bunch of
screenshots. I at least find this too confusing.
If we add support for european address formats, this is not going to get easier.
Which I would like to see, regarding comment 34. It'd be kinda unfortunate if 
each region had to go over this code again and tweak it.

Comment 44

[Mark Banner (:standard8)]

(In reply to comment #43)
> Living in a domain where US address notations make hardly any sense myself, I 
> see only limited value of over-engineering this, and if we have to, I don't
> see people understanding what they're supposed to do without having a bunch of
> screenshots. I at least find this too confusing.
> If we add support for european address formats, this is not going to get
> easier.
> Which I would like to see, regarding comment 34. It'd be kinda unfortunate if 
> each region had to go over this code again and tweak it.

Thanks for pointing this out Alex, I think you're right, we need to make it flexible enough for all locales whilst were here, and that would include being able to change the order of all the address book fields. Masayuki please can you look at extending the patch to include comment 34?

Can you also think about doing a page, possibly on devmo to cover the required information?

Thanks.

Comment 45

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #44)
> (In reply to comment #43)
> > Living in a domain where US address notations make hardly any sense myself, I 
> > see only limited value of over-engineering this, and if we have to, I don't
> > see people understanding what they're supposed to do without having a bunch of
> > screenshots. I at least find this too confusing.
> > If we add support for european address formats, this is not going to get
> > easier.
> > Which I would like to see, regarding comment 34. It'd be kinda unfortunate if 
> > each region had to go over this code again and tweak it.
> 
> Thanks for pointing this out Alex, I think you're right, we need to make it
> flexible enough for all locales whilst were here, and that would include being
> able to change the order of all the address book fields. Masayuki please can
> you look at extending the patch to include comment 34?

I can fix with the first format (1 item per line).
But it changes the size of dialog, is it allowed?
And if we should use second format, I don't have idea.

> Can you also think about doing a page, possibly on devmo to cover the required
> information?

It's not easy. I don't think that my poor English document will be good reference...

Comment 46

[Dan Mosedale (:dmosedale, :dmose)]

Worth keeping in mind, perhaps, is that in some ideal world, we'd include the ordering for all locales in the core itself rather than in the locale packs.  The idea here would be that you might well have correspondents in different parts of the world.  The locale pack would merely pick the default ordering, but if you filled in a different country into the country field, the pane/card would automagically adapt itself to the country in question.  That's complex enough that it probably merits its own bug just to investigate whether it's actually practical at all.  But it seemed worth mentioning here as food for thought.

Comment 47

[Axel Hecht [:Pike]]

I thought about that, too. I have this mantra of "local stuff shouldn't be 
localized", maps in addressbook is another of those.
But in this case, I'm not sure that we gain a whole lot. I doubt that the 
complexity of choosing an address layout is less than just entering a foreign
address in an odd format.
TB is not about printing mail envelopes, so I think it suffices to just get the 
general address across (which is why I'm not too sure this bug is a blocker).
If snail-mail address conformance is a requirement, I think that LDAP 
integration and mac (OS?) addressbook integration are a much higher priority.
One could sniff the country and then change the layout of the address pane, but
that smells like UE confusion. I doubt that beltzner would like that. I would at
least poke him about that.

Comment 48

[Axel Hecht [:Pike]]

Re #45, bad english is no argument ;-).

If you bring up the content, I or Sheppy can go over it and fix the language.
We won't be able to translate it from Japanese to English, though :-/

Comment 49

[Mark Banner (:standard8)]

Re Dan's and Alex's thoughts (comment 46 and comment 47) - I had thought about making the address book format depend on the country, however I see this as a useful stop gap until we're ready to do that.

(In reply to comment #45)
> I can fix with the first format (1 item per line).
> But it changes the size of dialog, is it allowed?
> And if we should use second format, I don't have idea.

I think use the first format (1 item per line). This will, as you say, change the height of the dialog.

I think the best way to compenstate would be to make the Home & Work Addresses on separate tabs. It would also help the other bug where we can't fit the card display on a 800x600 screen.

- Scott, Dan, any comments on this?

Comment 50

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: screenshot of the new address card dialog

not beautiful. should we separate the tab?

Comment 51

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: screenshot of the new separated tabs

Maybe, we can remove group box in these tabs.

Comment 52

[Mark Banner (:standard8)]

Scott, Neil, Dan what do we think of going with the separated tabs version for the time being and hence the dialog can be shorter?

The shorter dialog is a separate bug - but I don't want to make the dialog any taller with this change.

We can file a follow up bug to come to a better arrangement for the addresses later (possibly after TB 2.0/SM 1.1), i.e. some sort of better display whereby the addresses are on one tab, but you can switch between them as to which details you edit... or something like that

Comment 53

[Axel Hecht [:Pike]]

Attachment: us and eu address layout

I really think we should do this differently. Full adjustability of the address
layout just seems wrong to me, and somewhat backwards.

I'd rather have us have a limited amount of layouts in a <deck>, and have the
selectedIndex choose.
I attached a XUL with the layout of US and the layout I'd use in Germany in a
tab each, but it should be trivial to make that a deck.
Having this stuff in a deck gives us forwards compatibility, too, as we can 
easily decide to dynamically switch layouts later on.

This should make the code easier itself, and less error prone to localize.
It may make sense to move the address stuff into an XBL widget, even.

Other candidates for layouts to add would be Japan, of course, and maybe the UK.

Comment 54

[[e-mail]]

(In reply to comment #52)
>what do we think of going with the separated tabs version
You could even go as far as to convert each groupbox into a tab.

Comment 55

[Scott MacGregor]

(In reply to comment #54)
> (In reply to comment #52)
> >what do we think of going with the separated tabs version
> You could even go as far as to convert each groupbox into a tab.

Neil/Mark, are you suggesting not dynamically adjusting the elements, but instead using a "tab per region".

I think that's similar to the approach Axel is suggesting, giving each of the regions (us, eu, jp) their own deck. 

The downside for this approach includes: duplicated dom elements,.

But on the plus side, we wouldn't have to worry about explaining how localizers can control and re-order these elements. And it could be easier to maintain.

Comment 56

[Scott MacGregor]

(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #52)
> > >what do we think of going with the separated tabs version
> > You could even go as far as to convert each groupbox into a tab.
> 
> Neil/Mark, are you suggesting not dynamically adjusting the elements, but
> instead using a "tab per region".
> 

Chalk that comment up to severe jet lag. That's not what you were saying at all. 

I'm fine with separatoring work and home addresses into separate tabs.

The question is do we want to do that + dynamic ordering, or use Axel's deck idea, duplicating the content for several locales (us, eu, jp). 

I know where Axel stands, how about you Mark and Neil?

Comment 57

[Scott MacGregor]

(In reply to comment #56)
> I know where Axel stands, how about you Mark and Neil?

And Masayuki of course.

Comment 58

[Scott MacGregor]

Axel, Masayuki and I were just talking and thought it could be a good idea to post in the l10n newsgroup to see how many localizers would want to change / control the ordering of the address book fields. 

Comment 59

[Mark Banner (:standard8)]

(In reply to comment #58)
> Axel, Masayuki and I were just talking and thought it could be a good idea to
> post in the l10n newsgroup to see how many localizers would want to change /
> control the ordering of the address book fields. 

I got the impression from a previous post on l10n that there were a few. I'm quite happy with the idea of a deck or some way of providing multiple formats depending on the actual country of the address - I think that would be better than the re-order per locale that we've been proposing here.

What I have been wondering is if it is worth implementing the per locale format at this stage and do a deck/multiple formats later? Maybe it is better to do the full implementation now, even if it means missing the next major releases.


The Home/Work Address tab re-organisation suggestion, was mainly due to the extra length of the dialog for the re-order per locale option, which may be neccessary in any case so that will can fit the card on small displays (we still get the occasional comment that it can't fit on 640x480 or 800x600 whichever it is). I'm not sure if we'd need to do this if we changed to the deck option.

Comment 60

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #59)
> What I have been wondering is if it is worth implementing the per locale format
> at this stage and do a deck/multiple formats later? Maybe it is better to do
> the full implementation now, even if it means missing the next major releases.

It's very regrettable for me. But I'm working for 3.0 release in most time. So, missing on 2.0 is a good thing for my schedule. But who can work the difficult work? The way may be an ideal behavior, but it may be difficult work. If somebody can implement it before 3.0, I can approve the missing on 2.0. But not so, I cannot approve it... If nobody can work on it, we should use the current approach.

Comment 61

[Scott MacGregor]

minusing per the latest comments from masayuki and others.

Comment 63

[Pander]

Please, see duplicate https://bugzilla.mozilla.org/show_bug.cgi?id=407887 for some ideas.

Comment 64

[Wayne Mery (:wsmwk)]

Is this still a priority (jp-critical)?  

If so, does it make sense to look at this after 3.0b1?

Comment 65

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #64)
> Is this still a priority (jp-critical)?

Of course, yes. The current format is still unnatural interface for Japanese people.

> If so, does it make sense to look at this after 3.0b1?

But there are some issues which were written in comment 49, comment 53 and comment 59. I'm not sure which way is best for most users. If we need to switch the layout for each actual address, we need each standard layouts of many countries.

Comment 67

[Stefan Plewako [:stef]]

It should be also possible to disable (hide in preview/print preview and print) some fields.

BTW: http://en.wikipedia.org/wiki/Address_%28geography%29#Mailing_address_format_by_country

Comment 69

[Kohei Yoshino]

This add-on provides a workaround, using simple CSS and JavaScript:
https://addons.mozilla.org/thunderbird/addon/57220
via http://forums.mozillazine.jp/viewtopic.php?t=9573