Closed Bug 152962 Opened 22 years ago Closed 22 years ago

mozilla/config/base* files should include ucvja/ucvcn/ucvko/ucvtw/ucvtw2 convters

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ftang, Assigned: ftang)

References

Details

(Keywords: intl, topembed)

Attachments

(1 file)

We found out one common problems with several embedding project we have to
interact with is that by default the embedding application won't got
ucvja/ucvcn/ucvko/ucvtw and ucvtw2 conveters dll in it and therefore cannot
display japanese,korean, chinese 

This happen in several projects and we spend a lot of efforts on communication
and project management. Basically, when there are no decision making process
happen by default we got an non-internationalized embedding application. 
We need to change the files to include these dll so these optional dll will be
there by default and the embedding application developers can make decision to
take it out. Currently, those file do not include these dll so these optional
dll won't be there by default unless the embedding application developers make
decision to take it then they can move it. We want to make sure where no
decision making is in place, the embedding client is internalized by default.
And optimization COULD be done and remove them if the developer decide not to
take them. 

I have chat with jud valenski about this issue on AIM and he agree with this. He
ask me the file a bug, attach a patch, cc him and he will ask adam lock to r= it.

here is the bug. I will attach the fix right away.
I did'nt include ucvibm because it only contains charset converter for IBM main
frame and usually nobody will need it. 
jud- I need this change into trunk and branch for two mac clients. do we need
adt approval for embedding stuff? or edt approval itself is good enough ?
Blocks: 141008
Keywords: intl, nsbeta1+, topembed
How much will this add to the size of the default embedding application? We are
trying to avoid bloating out our app. We've made this available to our users as
an add on. It would be a hassle to have to strip this out if it is too much of a
burden.
The burden to add and remove are the same. It is a hassle to have to strip this
out. It is also a hassle to have to add this in. The question is why  don't you
need it?

I think any embedding appliction running on Windows, MacOS, Linux, Solaris, OS/2
, AIX, HPUX should need to have them becaues these OS have international support
and users. 

BTW, here re some marketing data can help embedding application developer make
decision about keep it or not

Internet population as today: see http://www.glreach.com/globstats/index.php3
total Internet population worldwide now: 560M users, project by 2003- 762M
Chinese Internet populatoin now: 55.5 M (9.8%) project by 2003- 125M (14.6%)
Japanese Internet population now: 52.1 M (9.2%) project by 2003- 75M (9.84%)
Korean Internet population now: 25.2M (4.4%) project by 2003- 35M (6.23%)

so... if any application want to ship a product which exclude 132.8 current
internet users (23.4% of total internet)/ 235M users by 2003 (30.67%) / 102.2M
internet users growth in 1.5 years (now to end of 2003), then they are free to
remove them from their embedding application. However, I think most of the
embedding application will care these 23.4% (and soon 30.67%) of internet users.

so.. back to answer of size in bytes (release build):
     Mac carbon   window   Linux
ucvja  183,271   171,376   184,908
ucvcn   96,038    75,872    88,964
ucvtw  124,246   115,936   123,828
ucvtw2 184,441   173,968   182,692
ucvko  116,494   101,904   115,196




For me currently is we already spend a lot of time to find out the contact
person inside my company on different project to ask them to add them into their
project. We already spend several days of work on findin the contact, negotiate
, find the engineer to do this on two of our internal projects. And currently, I
know at least two other projects have the same problem inside my company untill
we fix it here. this has not include the time that our QA wrote duplicate bug
report in different bug system for different project to report the same problem
in different langauges. Nor it include the time our QA spend to retest again and
again weekly untill they change it and verify it again after they fix that. 
Blocks: 150924
some how to mach-o binary are bigger. we look at it and it is total about 1M for
all these 5 dll
I have no issue with what the patch is doing, but I wonder why the embedding
dist needs all these language converters in it. Part of the reason the dist
exists is to demonstrate a *sample* subset of Mozilla for demonstration and
testing purposes. This just seems like bloat.

As far as I'm concerned we only need 1 language convertor - to verify unicode is
not broken - and can leave the rest out. So I would suggest pick one language,
e.g. Japanese to include and leave the rest commented out in the manifests.

If necessary we could add a note to readme.html to clarify the issue.
Frank,

We will be including this support but as an add-on. You are correct, we have
users who do need these support. But we include it as a separate download. That
helps us keep the main installation as small as possible while still allowing
the additional functionality for those who need it. As Adam noted, this has
always been the focus of the embedding development.
adam: As I mentioned above. We already spend endless hours talk to sevearl
embedding project to include those converters. As today, without any decision
making process, most embedding client only copy what is in the embedding dist
into their project. And we need to talk to different project to include them.
For every project we work on, we
1. IQA find the appliation does not work with Japanese/Chinse/Korean
2. IQA files bugs in different bug systems for those project
3. We (I18N engineer) find out the root of the problem 
4. We need to find out the project manager 
5. We prepare a presentation to tell them why they should include these dll
files and need to make a presentation to the project team. 
6. The project team will ask how many memory will be added to the build
7. We will tell them how many and they will said it could be too much. and we
negotiate several hours with them. 
8. Occutation, I need to escalate to my upper manger and ask my vp to talk to
their vp 
9. Then they said ok let's change it
10. Then I need to find out who is the engineer and tell them how to change it.
11. then They change it and IQA have to verify all the bugs that s/he file in
their project bug system and mark them fixed

Imaging we already did that twice, and I have do this for 3 more if we don't
change it. Consider how much of efforts my team waste on this issue for 4-5
different projects. 

>I wonder why the embedding dist needs all these language converters in it.
Very simple, without this patch, none of the embedding application will pass
Mozilla smoke test. Do you think I should ask IQA to test embedding application
with smoke test ? If they do today, none of the embedding application will pass
all the international smoke test. Don't you think the embedding dist need to
pass smoketest ?

There are another work around we can take if people disagree with this patch. We
can merge all the conveter dll into one big dll to solve this problem without
this change. But I don't think anyone want to see that, right ?


jud and adam do not agree to take this fix. mark it as won'tfix
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Please look at bug 154878 for an alternative approach.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: