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.
Created attachment 88372 [details] [diff] [review] config file change to include ucvja/ucvko/ucvtw/ucvtw2/ucvcn in the base distribution
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 ?
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.
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
Please look at bug 154878 for an alternative approach.