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",... morse@netscape.com 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...

Reassigned to 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.

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.

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.

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

Changed QA contact to andreasb@netscape.com while I am away.

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.

Jaime, we need your help here please comment. thanks

> 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?

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

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?

Changing QA Contact to ylong@netscape.com.

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

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.

Changed QA contact to teruko@netscape.com.

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?

My request of l10n is contained in the comments above. Namely: rchen@netscape.com 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. morse@netscape.com 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 rchen@netscape.com 2001-03-16 14:26

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.

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

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 :)

Adding Sol and Todd to cc list.

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.

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

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.

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

not gonna hold beta for this.

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?

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