Remove Hebrew and Arabic from Composer charset menu

VERIFIED FIXED in M14

Status

()

Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: bobj, Assigned: cata)

Tracking

({relnote})

Trunk
All
Other
relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] ETA: 22/Feb)

(Reporter)

Description

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M14
(Reporter)

Updated

18 years ago
Keywords: beta1

Comment 1

18 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 2

18 years ago
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!!.

(Reporter)

Comment 3

18 years ago
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.
Keywords: relnote
(Assignee)

Updated

18 years ago
Whiteboard: [PDT+] → [PDT+] ETA: 22/Feb
(Reporter)

Comment 4

18 years ago
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.
(Reporter)

Comment 5

18 years ago
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
(Assignee)

Comment 6

18 years ago
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

18 years ago
I verified this in 20000223 Win32, Linux commercial build and Mac mozilla build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.