62841 - defaults/wallet should contain/use different subdirs for localisations

Status: RESOLVED WONTFIX

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

Description

[Robert Kaiser]

Copying from bug 62689:

Currently defaults\wallet contains the files that contain the keywords that
allow to prefill forms with values like "name", "e-mail", "address",...
[e-mail] mentioned in another bug which he just fixed (I already
forgot the number), that additional languages could be supported by adding the
localized keywords to these files.
[...]
But there is another problem with that: current structure needs me to overwrite
en-US files in /defaults/wallet/ and so you won't be able to switch them back to
en-US or using different localised files for different profiles, and that's bad
IMHO.


As this is happening, we should have /en-US/ and /<langcode>/ directories there
as we have for defaults/profile.
Other possible solution would be to move the relevant strings to chrome...

Comment 1

[rchen]

Reassigned to Morse.

Comment 2

[Stephen P. Morse]

I just discussed this issue in answer to a question in bug 62427.  I'll repeat 
my comments here.  (Comments were addressed to a German web-developer, hence all 
the references to German websites.)

Bottom line is that i18n/l10n really has to decide which way they want to handle 
this so I'm reassigning this in order to get a decision made.

-------------------

There are two schools of thought on this.

One solution would be to have entirely separate tables for each language.  But 
that means that a person would a German-language browser would only be able to 
auto-fill forms from German websites.  That would be undesirable for 
multi-lingual people (such as yourself) who sometimes visit websites in their 
native language and other times visit english-language websites for example.

The other solution is to put the foreign strings into the same table that had 
the english strings, resulting in one big monolithic table.  Could be more of a 
maintenance head-ache but would solve the multi-lingual problem.

Some middle-ground might be to have different tables for various language 
groups.  For example, you might want to have a table that included English, 
German, and maybe French (since you are so close to that country) but would have 
no desire for Japanese in your table.  Maybe we could even have a tool that lets 
the user decide what languages he is interested in and the correct composite 
table is generated for him.

Comment 3

[rchen]

cc danielmc,laurasl,bobj,ftang,momoi. You are welcome to put your comment if you 
like.

I don't see the problem to support multi-lingual, since we always can use 
unicode (UTF-8) for the table. I think it's not a bad idea to have a table that 
includes some major languages in the same region and a tool that lets the user 
to download languages and give the correct composite table. 

Comment 4

[Karl Ove Hufthammer]

I think the best solution is to have several tables, one for each language, but 
that *all* languages should be available at all web pages (the tables need to 
be checked into CVS then).

One more thing: It should be possible to have several translations (in one 
language) for each "keyword".

Adding l12y keyword.

Comment 5

[Stephen P. Morse]

nominating this for nsbeta1. we need some intl team input to make the decision. 

Comment 6

[Teruko Kobayashi]

Changed QA contact to [e-mail] while I am away.

Comment 7

[rchen]

I am going to call a meeting to discuss this before it's too late.

Anyone who has other proposals is welcome to put them here.    

Comment 8

[Michele Carlson]

Jaime, we need your help here please comment.
thanks

Comment 9

[bobj]

> Maybe we could even have a tool that lets  the user decide what languages
> he is interested in and the correct composite table is generated for him.
Or do we need pref UI to select which languages?

Does multilingual support have any implication on storing and managing saved
passwords?

Comment 10

[Stephen P. Morse]

Saved passwords is password-manager and so has nothing to do with this bug 
report which involves form-manager.

Comment 11

[rchen]

Attachment: This is the detail document of Form Manager Table.

Comment 12

[Stephen P. Morse]

Attachment: Same attachment but easier to read

Comment 13

[rchen]

I made the conclusion based on the document of Form Manager Table from the 
localizatiopn point of view: 

DistinguihedSchema.tbl - No localization involved. 
FieldSchema.tbl - <field name> is a good candidate for localization. 
VcardSchema.tbl - No localization involved. 
SchemaConcat.tbl - The order of <subschema name> can be changed for different                    
locale. 
SchemaStrings.tbl - <screen string> is a candidate for localization. 
PositionSchema.tbl - The order of the <schema name> or $<state schema name> can                                           
be changed for different locale. 
StateSchema.tbl - <state> is a candidate for localization. 

Here I assume we don't localize <schema name> so that we can share the same data 
across the different locales. But there will be a problem to have different 
orders for different locale in SchemaConcat.tbl and PositionSchema.tbl if more 
than one language exists in the same table.  

There could be an alternative - localize <schema name>, which actually can 
generate different data for different locales, for example, the user may want to 
have English name filled in US web sites and Japanese name filled in Japanese 
web sites. It also solve the problem of SchemaConcat.tbl and PositionSchema.tbl 
since they are in different <schema name>.

After discussion with Bob Jung and Steve Morse, we come out with the two plans, 
the long term solution and the short term solution.

The long term solution - Just like the middle-ground solution suggested by 
Steve. There are different default tables for various language regions.  For 
example, a table in German language includes English, German, and maybe French  
but no Japanese.  There will be a tool which allows the user select the 
region/languages and create the composite table he needs afterwards.

The short term solution - Just allow the developers to bundle more than one 
language in one table file. User won't have a tool to change it. The developers 
will decide whether to localize <schema name> in their tables.

Bob and I incline to have the short term solution for 6.5 and the long term 
solution for 7.

Any comments?

Comment 14

[Andreas Becker]

Changing QA Contact to [e-mail].

Comment 15

[rchen]

Steve, you already ahve our input. If you still have any questions, please let 
me know.  I pass the bug to you.

Comment 16

[Stephen P. Morse]

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 adding entries to 
the tables  for languages that I do not speak.  IMO this is a task for the l10n 
team but they assigned it back to me.

Comment 17

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 18

[Jaime Rodriguez, Jr.]

Vishy - Pls change nsbeta1+ to nsbeta1-. This is not needed for beta, but will 
be needed by M0.9.2.

Steve - Can you pls be more specific in your request of L10N?

Comment 19

[Stephen P. Morse]

My request of l10n is contained in the comments above.  Namely:

[e-mail] 2001-03-16 14:26

    The short term solution - Just allow the developers to bundle more than one 
    language in one table file. User won't have a tool to change it. The
    developers will decide whether to localize <schema name> in their tables.

[e-mail] 2001-04-10 18:14

    there is not much I can do to close out this report because it involves
    adding entries to the tables  for languages that I do not speak.  IMO
    this is a task for the l10n team but they assigned it back to me.

And for more details of just what is in these tables and what localization needs 
to be added, see [e-mail] 2001-03-16 14:26

Comment 20

[Cindy Roberts]

Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have enough time in eMojo to fix this.  Let's revisit for MachV.

Comment 21

[elaineking]

removed keyword nsbranch since it now has nsbranch-, per pdt mtg.

Comment 22

[simon.hetzer]

If doable, I as an user 'd like to see a list of installed lang-packs under
Edit/Preferences/Privacy & Security/Forms
with Checkboxes in front of every language, so I can add/remove the schemes for
the languages easily.
This would make it neccessary to have different schemes for each language but
Mozilla has to combine them and make one big scheme.
This is just my dream, and my comment :)

Comment 23

[Jaime Rodriguez, Jr.]

Adding Sol and Todd to cc list.

Comment 24

[Michele Carlson]

todd and sol - how high priority is for fixing this? Right now it's not usable
for foreign language versions. But if it's low priority, then let's close this
bug (or future it). If it's a priority, then we can look at fixing it.

Comment 25

[Thomas R. (TRauMa)]

If this is still in work, i have some ideas:

we have the preffered languages option, right? So let's search for password
keywords in the order that's given there? So, for me it would look like

my preferences:
1 de-DE
2 en

Look for "Benutzer(name), Passwort", then look for "user(name), password"
But don't look for french versions since i don't speak french.

This implies that the en moz has to know all these words in as many as possible
languages. Perhaps we should open a new bug where all l10n teams can post their
translations as comments or attachments. these are unlikely to change so that
bug should be a browser bug.

All of this imho... :) Hope it's useful

Comment 26

[Markus Hossner]

Attachment: Idea for a new kind of form-manager mechanism

I think to localize the acutal form-manager mechanism is a nearly
unsolvable problem.
If you change the keywords completely into another language, you
can't work with English forms any longer.
If you make more than one language availibile at the same time,
the first problem will be, how to find out the language of the page
and second problem same langauage doesn't mean same form of addresses.
A opportunity to choose the language(land) per hand, will not
very useful, cause it means a greater context menu or more work
to fill in the froms.

Therefore I though about a new mechanism for the form-manager.
My thoughts came to a system of global and local variables
I made a picture to show you what I mean. You can find it here:

"Idea for a new kind of form-manager mechanism"

The pic shows a kind of UI with which you can manage the stored
form data.
 
The name of a variable is the name of the textfield.
There are global variables which will be valid for all sites.
There you will find the usual discribtions of textfields
(firstname,forename,vorname,...). All this global variables are
stored with their value. The catalog will grow during working with
it, cause it will learn more and more variables. The global variables
could be created by hand or they can be imported from the list of
local variables(See pic).
 
The local list is the list for already known sites. The local variables
are dominant. If there is a local and a global variable for one field
the manager will choose the local one.
You can del the local variables if there are duples of global variables or
you can close local variables if you don't want the manager to chance the
entry of this textfield when filling the form.
This system also give you the ability to choose different email-
addresses for some sites(See pic), but also have a standard email-adress
in the global variables.
This mechanism will guarantee that a know form is filled correctly and
will also help to prefill a unknown form.

I hope for comments about my idea.

Comment 27

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Another localization blocker, reassigninig to new Form/Password Manager owner.

Comment 28

[Asa Dotzler [:asa]]

not gonna hold beta for this.

Comment 29

[Thomas]

If I understand well this bug is best discribed by comment #19, but as far as I
know Mozilla is currently pretty localised. How was this implemented?

Comment 30

[Robert Kaiser]

Wallet will be killed off soon by bug 304309, closing this bug.