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

Status: RESOLVED WONTFIX

(Core Graveyard :: Embedding: APIs, defect)

Description

[Frank Tang]

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.

Comment 1

[Frank Tang]

Attachment: config file change to include ucvja/ucvko/ucvtw/ucvtw2/ucvcn in the base distribution

Comment 2

[Frank Tang]

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 ?

Comment 3

[amutch]

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.

Comment 4

[Frank Tang]

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

Comment 5

[Frank Tang]

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. 

Comment 6

[Frank Tang]

some how to mach-o binary are bigger. we look at it and it is total about 1M for
all these 5 dll

Comment 7

[Adam Lock]

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.

Comment 8

[amutch]

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.

Comment 9

[Frank Tang]

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 ?

Comment 10

[Frank Tang]

jud and adam do not agree to take this fix. mark it as won'tfix

Comment 11

[Adam Lock]

Please look at bug 154878 for an alternative approach.