Closed Bug 62730 Opened 24 years ago Closed 23 years ago

Move file into Locale Directory

Categories

(Core :: Internationalization: Localization, defect, P2)

Product:
Core
Component:
Internationalization: Localization
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: Sebastian, Assigned: morse)

References

Details

(Keywords: l12y)

Attachments

(4 files)

Description of Wallet Tables (posted per rchen request)
6.15 KB, text/plain
Details
patch to put xul files into the en-US.jar file
11.26 KB, patch
Details | Diff | Splinter Review
patch for extensions/wallet
12.32 KB, patch
Details | Diff | Splinter Review
Experiment to fix not finding "localizable" XUL files
1.86 KB, patch
Details | Diff | Splinter Review 
The form manager offers the possibility to prefill you personal information e.g.
the zipcode in the format xxx - xxx.
Well, I live in Germany and we only have one number as zipcode, where to fill it
in and which field to leave empty?

You can take this as a more general bug: Items need a more describtive and(or
example text.
That's not just a nitpick but actually an important comment.

As mentioned in bug 62727 and 62749, the dialog that you are seeing was just 
introduced into the build yesterday.  The dialog that it replaced was actually 
schema neutral and language neutral.  That is, every schema was presented by its 
name along with the value that it contained.  There was no attempt at 
interpreting a meaning on the schema and therefore no attempt to present the 
different schema to the user in a logical fashion (such as putting the two parts 
of the zipcode alongside each other).  That had the advantage of not needing to 
be localized but the disadvantage of not being that easy to understand.

This new dialog is certainly dependent on locality.  Addresses in general are 
something that vary in different countries (in Japan I believe the entire 
address is written on a single line).  So this dialog (xul file sas well as dtd 
file) will need to be customized for the different languages.

I'm keeping this bug open as a reminder to do the localization of these xul 
files.  Assigning it to the l10n team.
Assignee: morse → rchen
Component: Form Manager → Localization
QA Contact: tpreston → teruko
Reassigned to ftang.
Assignee: rchen → ftang
one of the collection of the address formats used in different countries could
be found at
http://msdn.microsoft.com/library/books/devintl/S25D1.HTM

morse, can you design your dialogbox based on this information ?
Assignee: ftang → morse
That collection of address formats is very interesting and certainly of help in 
customizing the dialog for each locality.

Now the question comes up as to who should do this.  I did the dialog for 
US-english format.  Wouldn't it be the l10n team that does an equivalent dialog 
for each country that we want to support?  If that's true, then this bug 
shouldn't be assigned to me but should go to someone in the l10n team.
Adding roberts to cc: list.
No Steve, the localization team is not responsible for this change; UI has to be
properly designed for internationalization. IFrank (i18n, not l10n) may be able
to help you. You may want to look at addressbook UI or talk to Paul Hangas. If I
recall correctly he did it for AB.
Summary: [nitpick] how to handle zipcode et al.? → how to handle zipcode et al.?
Adding nsbeta1 and l12y keywords.
Keywords: l12y, nsbeta1
Priority: P3 → --
Target Milestone: --- → mozilla1.0
Status: NEW → ASSIGNED
Steve, l12y bugs have to be fixed before beta1. Please, reconsider milestone.
Keywords: mozilla0.9
Ray/Bobj - Didn't we talk to Steve about this bug already.

Also, I'm confused as to why this bug is marked as M1.0 and given a severity of 
trivial, if Steve says ". . . not just a nitpick but actually an important 
comment."
Steve,
I would suggest you to post the wallet document with instruction here or news 
group for outside developers so that they know the way to implement the 
different formats if they like. 
Per vishy's request, my recommendation for this is nsbeta1+.  However there is 
not much I can do to close out this report because it involves formatting 
dialogs for different local customs of which I am not familiar.  IMO this is a 
task for the l10n team but they assigned it back to me.
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2
L10n engr team does not do core engineering feature work.


I agree with MCarlson's comments, L10N does not do core feature development, nor
do they provide market specifications.

Questoins for Steve - - 

Is this a schema table issue (i.e. Is the user only impacted when they try to
enter into Preferences |Forms)?

Can the user add a localized field to the schema table, via 'SaveForm Data'?
Hello Steve? A little information . . ..
Sorry for not responding.  I didn't understand the question.  I'll give you a 
call so we can discuss this.
Changing Summary to better reflect the work we need morse to do for this cycle,
as oppossed to iCPM and L10N.

I think we should move the XUL into locale folder, and International PM (i.e.
Jaime) should define the dialogue for L10N (Note: Need to open a bug for each
geography, assigned to jaimejr for definition, then to danielmc, and michele for
engineering).

Tao? - Is this moving this XUL dialogue into Locales the right thing to do, if
we need to localize for each geography?
Summary: how to handle zipcode et al.? → Move file into Locale Directory
Target Milestone: mozilla1.0 → mozilla0.9.1
Attaching a patch that puts the xul files requiring localization into the locale 
en-us.jar file rather than the comm.jar file.  Is this proposed change 
sufficient to make sure the these xul files will get localized?

This is the way all localizable files (.dtd and .property) for wallet and 
cookies are currently handled.  And they are currently getting localized so this 
is obviously working.

I realize that the more desirable thing is to restucture the folders so that we 
have a separate content folder and a separate locale folder.  But is it really 
necessary to do all that just to get the current xul files in question 
localized?

Tao, Jaime said that you were the person who could answer this question.

Moving XUL files to en-US.jar is a short term work around. The long term solution
might be the combination of XUL overlay and template which is more localization 
friendly. 
tao, if you agree that this will fix the problem, at least in the short term, 
could you please put your r=tao here.  Thanks.
Adding dveditz to cc: list for architectural direction on how to best implement
this change.
Hi, Steve:

How do we change the layout of the Address fields? In other words, which files
to modify?

thx
The files that you would need to modify in order to change layout of addresses, 
for example, in order to meet local conventions are the xul files that I am 
moving to the en-US.jar file in the patch.
tao, please review this patch.
r=rchen
cc'ing alecf for sr
Should this be in the region pack not in the language pack? This information is 
region,  not language specific.
Daniel - Sounds like a good idea to me.

Morse - Since this information is geographically limted, not language, a better
place to put this information, might be in the content packs for each geogrpahy.
I don't know how to put things in the content packs.  Is there someone else who 
should be taking over this bug?  If not, give me more details and I'll do it.
Morse - Tao would be the best person to help, but he is on vacation. Requesting 
help from Bobj, Ftang, Danielmc or RChen.
leaf may know the details of packaging.

cc leaf.
nav triage: its too late to complete this bug. morse has taken it pretty far, 
has patches,  but we need someone from i18n group to own this one now to take it 
to completion. moving to mozilla0.9.2 at least.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Agreed - M0.9.2 WFM. Pls updating keyword, with a minus for nsbeta1.
Severity: trivial → minor
Keywords: nsbeta1+ → nsbeta1-
nav intl triage: accepting for m0.9.2, P2. 
I talk to rchen about this and we are not 100% sure what should be done to move 
it to US.jar
but here is our guess. morse, can you try it?

1. in extensions/wallet/jar.mn create another group
US.jar: under the last iine. I think you need add a empty line as delimeter.

2. move the following from under en-US.jar: to under US.jar: . also, change the 
path from locale/en-US/wallet/ to locale/US/wallet/


+    locale/US/wallet/WalletAddress.xul                     
(editor/WalletAddress.xul)
+    locale/US/wallet/WalletBilling.xul                     
(editor/WalletBilling.xul)
+    locale/US/wallet/WalletConcatenated.xul                
(editor/WalletConcatenated.xul)
+    locale/US/wallet/WalletCredit.xul                      
(editor/WalletCredit.xul)
+    locale/US/wallet/WalletEmploy.xul                      
(editor/WalletEmploy.xul)
+    locale/US/wallet/WalletMisc.xul                        
(editor/WalletMisc.xul)
+    locale/US/wallet/WalletName.xul                        
(editor/WalletName.xul)
+    locale/US/wallet/WalletOther.xul                       
(editor/WalletOther.xul)
+    locale/US/wallet/WalletPhone.xul                       
(editor/WalletPhone.xul)
+    locale/US/wallet/WalletPrimary.xul                     
(editor/WalletPrimary.xul)
+    locale/US/wallet/WalletShipping.xul                    
(editor/WalletShipping.xul)
+    locale/US/wallet/WalletUrlspecific.xul                 
(editor/WalletUrlspecific.xul)

Not 100% sure this will work. But can you try ? thanks

steve- your patch does not work in my system Have you test it before you submit 
?
I'm sure I tested it once upon a time.
here is a new patch which work on my system I only change the jar.mn, 
makefile.win and Makefile.in from you patch. The first two files should be the 
same.
r=morse
Keywords: nsbeta1- → nsbeta1+
cc'ing alecf for sr
Whiteboard: patch available, awaiting reviews
ouch... this seems like a huge burden to place on localizers, but sr=alecf
Blocks: 83989
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)

Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
With this change, dialogs launched by:
Tasks | Privacy and Security | Form Manager | View Captured Form Data
are no longer constructed properly. I'm getting the JS error:
chrome://communicator/content/wallet/WalletViewer.js line 124: elementIDs has no
 properties
when dialog loads.
Is anyone seeing this in optimized builds?
I tried clobbering the wallet directory, do I need to do a complete clobber
build to correctly relocate wallet UI?
Blocks: 82655
Blocks: 84961
I'm seeing the problem too.  Reopening.

ftang, can you revise the patch to avoid this regression?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
With my build from 6/9, I could "fix" the missing widgets by changing "locale"
back to "content" for the XUL chrome URLs. Then I did a complete clobber build,
and now I can't seem to fix this in the same way. I think there's some mixup
with trying to put localizable files (just DTD?) in "locale" directories, but
keeping the XUL files in "content" directories.
Note that there wallet preview and overlay JS and XUL files are in "comm.jar",
but the wallet XUL files relating to editor are in "us.jar", but the
url to reference these is: "chrome://communicator/locale/wallet/..."
(e.g., "communicator/locale/wallet/WalletName.xul", the source of the content
for editing the "Name" items). This seems to be the source of the problem.
Why were XUL files move from the "content" subdirectory in the jar file?


Sorry, nevermind my last question, I see why we wanted to move XUL files into
localizable area, but I agree with Alec: what a lot of work to expect from
localizers!
Ok, try the "Experiment" patch from 6/10, which copies entries for all the xul
files we want to localize into the "en-us.jar" part of jar.mn. (I did not delete
them from the "us.jar" section).
Everything works with this patch. So obviously the files are not being found
when placed in "us.jar" because of the automatic country-searching done when
"locale" directories are used, correct?
So is the final fix to simply put these in 'en-us.jar' as I have done, but
eliminate 'us.jar'? Why was "us.jar" used in the first place?

Charlie, it looks like you are experimenting with putting the files into the 
en-US jar file instead of the US jar file.  This is what I attempted in patch id 
32651 (4-30).  But that's not what l10n wanted.  They wanted the files put into 
region packs, not language packs.  That's why they wanted to use US jar instead 
of en-US jar.

The difference between a language pack and a region pack, if I understandit 
correctly, is that the former has to do with the translation of strings into the 
language and the other has to do with local conventions of the region (does 
month precede day or day precede month in a date, etc).
Well, that may be what they want, but they didn't get it right! My suggested
patch wasn't intended as the final fix, but only to prove it wasn't my changes
and to give us a short-term method to be able to test the UI and close bug 82655.
Could you retest that with my patch here so we can close 82655? It worked fine
for me.
Charlie, your experimental patch of 6/10 does not work for me.  I still get a 
blank right-half in the dialog.
Blocks: 84957
Whiteboard: patch available, awaiting reviews
I'm going to re-close this because we have done what the bug report asks for -- 
i.e., move the files to to the locale directory.  But in the process we broke 
something else.  It's bad to morph a bug report.  And sfraser has opened bug 
85300 for the new problem.  So I've cc'ed all the people on this report into the 
new report.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
No longer blocks: 82655
I will suggest we either back out 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36541 for now or 
take charles work around 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37839 for now untill we 
find out the real fix.
I verified this in 7-26-0.9.2 and trunk build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: