** Observed with 7/26/99 Win32 build ** Now that we can translate .dtd files in the locale directories associated with each .xul file, we should be able to just translate messengercompse.xul file's entity definitions, but this fails gerenally with messengercompose.dtd file. For example, none of the Character Set menu items are in the .dtd file. I noticed the problems with "Character Set" menu items but there may be others also. I believe the reason is that messengercompose.xul file does not use ENTITY definitions sufficiently to ensure that all necessary entities are extracted by tao's utility. I don't know who should fix messengercompose.xul, but I'm going to send it initiatlly to jean-f.

I get a fix in my Mac, I am waiting on the tree to open to check in. Anyway, I think we should use overlay for the charset menu instance of having a copy in every project. I18l folk should own the overlay!

Jean-François, I agree with you about the template/overlay. The charset menus need to be re-done incorporating the final UI spec and i18n should own it. For now, it would be sufficient to have a current version of properly constructed .xul file for our purpose.

I have copy the charset menu of messenger.xul into messengercompose.xul. Fixed and checked in.

One question: the Charset menu in messenger.xul is not the same as the menu in messengercompose.xul. The latter is much shorter since we use only the standard charset for each language/encoding group in sending mail. Is this what you checked in?

oops, I think I messed up here. I will redo it and be sure I still have the samemenu items than before. Reopen the bug!

Clearing Fixed resolution since Re-opened

Ok, I get a new fix, the right one this time but something when wrong (RDF?) in the tree since last time and hangas totally disable the charset menu. I will have to wait that everything works fine again before check it in. FYI, here is the menu I will check in: <!ENTITY viewMenu.label "View"> <!ENTITY showCmd.label ".Show"> <!ENTITY addressCmd.label ".Address"> <!ENTITY attachmentsCmd.label ".Attachments"> <!ENTITY wrapCmd.label ".Wrap Long Lines"> <!ENTITY dcharMenu.label "Character Set"> <!ENTITY dcharIso1Cmd.label "Western (ISO-8859-1)"> <!ENTITY dcharIso2Cmd.label "Central European (ISO-8859-2)"> <!ENTITY dcharIso3Cmd.label "Esperanto/Maltese (ISO-8859-3)"> <!ENTITY dcharIso4Cmd.label "Baltic (ISO-8859-4)"> <!ENTITY dcharIso9Cmd.label "Turkish (ISO-8859-9)"> <!ENTITY dcharIso10Cmd.label "Northern European (ISO-8859-10)"> <!ENTITY dcharIso14Cmd.label "Celtic (ISO-8859-14)"> <!ENTITY dcharIso15Cmd.label "New Western (ISO-8859-15)"> <!ENTITY dcharJapanCmd.label "Japanese (ISO-2022-JP)"> <!ENTITY dcharTradChiBigCmd.label "Traditional Chinese (Big5)"> <!ENTITY dcharSimpChiGbCmd.label "Simplified Chinese (GB2312)"> <!ENTITY dcharKoreanCmd.label "Korean (EUC-KR)"> <!ENTITY dcharUtf8Cmd.label "UTF-8"> <!ENTITY dcharRusCmd.label "Cyrillic (KOI8-R)"> <!ENTITY dcharUkrCmd.label "Ukrainian (KOI8-U)"> <!ENTITY dcharIsoGreekCmd.label "Greek (ISO-8859-7)"> <!ENTITY dcharVietViCmd.label "Vietnamese (VISCII)"> <!ENTITY dcharThaiCmd.label "Thai (TIS-620)"> <!ENTITY dcharArmCmd.label "Armenian (ARMSCII-8)">

The Charset menu items are correct. I wonder about other items not related to Charset menu like "File" menu name, for example. I had trouble displaying it when I translated it. Were there others you needed to define as entities in addition to Charset menu related items?

Checked in the new menu.

** Checked with 7/30/99 Win32 M9 build ** I'm now able to localize many of the items into Japanese. Bit there are some remaining problems. They are of 2 types: 1. Types, when localized using 8-bit charactesr, cause a crash. FileMenuLabel ENTITY (messengercompose.dtd) tasksMenuLabel ENTITY (tasksOverlay.dtd) 2. Types, when localized, simply do not show as changed. These are probably due to improperly constructed XUL. insertMenuLabel (messengercompose.dtd) formatMenuLabe (messengercompose.dtd I'm re-opening this bug for these reasons

Also, this is trivial but we need a sepator for each of the ISO entries and also for the 2 Chinese entries. (This can wait until later, however.)

I spoke with momoi and as this menu will be in the future build dynamically, I won't spend time on it for now

Added cata to cc list.

Added cata to cc list.

Right/ The menu separator is a trivial issue but we need to address the crash problem with the translation of "File" and one other item earlier than this. In factm it should be investigated for M9.

For the crashing bug, I'm making available a modified "messengercompose.dtd" at the above URL. I made one modification in this file, i.e. I changed the following line: <!ENTITY fileMenu.label "File"> to <!ENTITY fileMenu.label "Fête"> then converted it to UTF-8. The above file is in UTF-8. If you use this file and open the Message compose window, 5.0 will crash. Here's part of the Talkback report available for one such crash: ------------------------------------------------ Trigger Type: Program Crash Trigger Reason: Access violation Call Stack: (Signature = MSVCRT.dll + 0x1663 (0x78001663) 2ce8f288) MSVCRT.dll + 0x1663 (0x78001663) xpcom.dll + 0x15080 (0x60b15080) raptorhtmlpars.dll + 0x35a9 (0x60a735a9) raptorhtmlpars.dll + 0x3683 (0x60a73683) raptorhtmlpars.dll + 0x158f3 (0x60a858f3) raptorhtmlpars.dll + 0x15732 (0x60a85732) raptorhtmlpars.dll + 0x15700 (0x60a85700) raptorhtmlpars.dll + 0x13eb6 (0x60a83eb6) raptorhtmlpars.dll + 0x2f6e (0x60a72f6e) raptorhtmlpars.dll + 0x2ff9 (0x60a72ff9) raptorhtmlpars.dll + 0xc669 (0x60a7c669) raptorhtmlpars.dll + 0xc2fb (0x60a7c2fb) raptorhtmlpars.dll + 0xc59d (0x60a7c59d) ------------------------------------------------ Tao, who should look at the crashing bug?

It's more an entity problem than a message compose problem. I need to reassign this bug to the right person but who?

CC Nisheeth.

Please open a new bug describing the crash, attach the offending file to the bug report, and assign the bug to me. I'll look into it. Thanks a lot.

I filed the crashing bug as Bug 11724. There was another report of the crash on one of the files I mentioned above, tasksOverlay.dtd and so this is not an isolated problem. The remaining problem for this bug is item #2: 2. Types, when localized, simply do not show as changed. These are probably due to improperly constructed XUL. insertMenuLabel (messengercompose.dtd) formatMenuLabe (messengercompose.dtd)

Adding myself to the CC list because my bug depends on this. Any chance the target milestone could be changed to M10 ?

Actually, I also need to request a fix by M10. Localization has to start at that milestone.

Momoi, 1) Do you still have the problem #2? 2) if yes, could you attach a modified dtd files for testing. Thanks

** Checked with 9/14/99 Win32 M11 build ** For these 2 specific items, insertMenuLabel (messengercompose.dtd) formatMenuLabel (messengercompose.dtd) the current status is: Worksforme. formatMenuLabel is still in messengercompose.dtd file, but the insertMenuLabel and all its submenu items come from chrome\editor\locale\en-US\editorOverlay.dtd Editing these strings do get reflected in the menus. One thing confusing stil is that the messengercompsoe.dtd file still conatins this line: <!-- Insert menu items --> <!ENTITY insertMenu.label ".Insert"> But translating this menu has not effect and you need to translate the one in editorOverlay.dtd and also all the submenus under Insert menu come from editorOverlay.dtd and the insertMenuLabel is defined there, too. On the other hand, there is only one 'formatmenuLabel" definition and it is in "messengercompose.dtd" and then all the submenus of this are in "editorOverlay.dtd". Confused? It seems to me that as we put things in global overlay files, we need to clean up this type of redundancies as much as possible. Does L10n have a strategy for this? Jean-f, can you clean up these redundancies?

Forgot to mention that formatmenuLabel is also defined in "EditorAppShell.dtd" file too. But there again all the submenus of this are in the "editorOverlay.dtd" file. Once we elimnate these redundancies, we should mark this bug as Worksforme or Fixed.

OK, I have removed the duplicated insertMenu.label from messengercompose.dtd (but not yet check in). Simon, why the FormatMenu.label isn't part of the editor overlay like its submenu? any good reason for that?

I've just checed in the cleanup for InsertMenu.label

M14

what remains to be fixed? By reading the report it looks like everything is fixed but then it's moved to M14. What did I miss?

Only stuff missing but probably not a bug or a problem is the fact that editor doesn't define the menu format itself as an overlay and therefore we have two identical DTD entry for FormatMenu.label. One in msgcompose and one in editor. I let this bug open just as a reminder. BTW, I've changed the summary to reflect the real issue.

Feel free to move entities around in the editor files; just make sure that they are there for the plain text and HTML editors.

That's why the menu format isn't fully defined as an overlay. Right? it's depending on the format (HTML or plain text)?

Kat, can you confirm that without this bug fix, we won't be able to localize?

Phil, as far as I know, this is a matter of redundancy not that of impairing localizability. This item apparently is not used at all as translating it has no effect. What I wanted was that as we move items to global overlay files, we don't leave behind items which had been moved. We should do general cleaning up like this regularly, but for me this is a low priority bug at this point.

Apparently, today you cannot use an entity defined into an dtd file you don't include yourself directly. Therefore, I cannot use directly an Editor entity into msg compose.I don't know if it's a limitation or a bug!

moved to M16

Oops. Really marking M18 now...

What's left for this bug? It seems just cleaning up the file -- removing FormatMenu.label out of editorOverlay.dtd, isn't it, Kat?

Sorry but we cannot fix that, it's a overlay limitation.

Then all important issues have been resolved. What remains is not critical or important. Verified as wontfinx.