28135 - Remove Hebrew and Arabic from Composer charset menu

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[bobj]

Since Hebrew and Arabic support are not planned for the 6.0 release,
they should be removed from the menus, so end-users are not confused.
This should be done before Beta1, so the wrong expectations are not set.

Comment 1

[leger]

Putting on PDT+ radar for beta1.

Comment 2

[moshev]

Now that IBM is sponsoring BiDi development, Is it still true
that 6.0 would not have Hebrew/Arabic support?
Also, even if BiDi is not available, why
not let the user the ability
to at least read/type backwards?
It works and is usable now, so i see no reason to remove 
the character sets from the menu (they are merely used
to choose the appropriate font). This is not confusing!!.

Comment 3

[bobj]

BiDi development is occurring, but it is not clear in which release it will
land.  At this point, we cannot commit that it will land in the first
Seamonkey release.

For sophisticated users, it is fairly easy to re-enable these menus by
editing external text files.  For the un-sophisticated users, I think it would
be misleading and confusing to have these menus present when "full" Hebrew
and Arabic support is not enabled.

We will document in the release notes how to re-enable these.  In the current
implementation, it is done by editing .xul files.

Note, the implementation of these menus will change after Beta1 to use the 
implementation used for the browser character coding menu.  To re-enable the
menu items for this method, you need to edit the charsetData.properties
file instead of .xul files.

It would be interesting for someone to put together a laundry list of items
that we would need to support visual order.  Do we limit this just to browsing?
How does input work for forms?  What UI needs to change (e.g., change menu
to Hebrew Visual (xxx)?)?  What would happen when encountering a logical-ordered
page and how to provide user feedback when it displays incorrectly?   If
all the issues could be resolved, we might be able to re-enable these menu
entries.

Comment 4

[bobj]

We should add a note to the release notes on how to re-enable these for Beta1.
If we merely comment them out of the .xul file, then the release note info
will be trivial.

Comment 5

[bobj]

I think this requires commenting these lines:

318                  <menuseparator />
319           <menuitem value="&dcharIso6Cmd.label;" 
accesskey="&charsetArabic.accesskey;" 

And change this line:

 118 <!ENTITY dcharMenu3.label "Character Set  SE Asian/Armenian/Semitic">

to:
 118 <!ENTITY dcharMenu3.label "Character Set  SE Asian/Armenian">

in

http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/locale/en-US/editorOv
erlay.dtd#118
oncommand="EditorSetDocumentCharacterSet('ISO-8859-6');"/>
320           <menuitem value="&dcharCp1256Cmd.label;" 
accesskey="&charsetWinArabic.accesskey;" 
oncommand="EditorSetDocumentCharacterSet('windows-1256');"/>
321                  <menuseparator />
322           <menuitem value="&dcharIso8Cmd.label;" 
accesskey="&charsetHebrew.accesskey;" 
oncommand="EditorSetDocumentCharacterSet('ISO-8859-8');"/>
323           <menuitem value="&dcharCp1255Cmd.label;" 
accesskey="&charsetWinHebrew.accesskey;" 
oncommand="EditorSetDocumentCharacterSet('windows-1255');"/>

from this file:

http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/editorOverlay
.xul#318

Comment 6

[cata]

Fixed.

Comment 7

[Teruko Kobayashi]

I verified this in 20000223 Win32, Linux commercial build and Mac mozilla build.