This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Here is a recent email exchange on this topic: ======================================== email #1 Date: Mon, 17 Jun 2002 09:08:30 +0200 From: Ales Kemr <ales.kemr@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Frank <Ken.Frank@sun.com> CC: ffj-iteam-uc@sun.com, Jesse Glick <jesse.glick@sun.com>, Michal Zlamal <michal.zlamal@sun.com> Subject: Re: NBM localization and Update Center Content-Transfer-Encoding: 7bit Hi, I vote for following structure and naming (to be consistent with other localized files): example.nbm | |-Info | |- info.xml | |- locale | |- info_ja.xml Frank, if there won't be objections, could you please file IssueZilla ENHANCEMENT against autoupdate to allow AU client recognize proper localized info.xml? CCing Michal and Jesse because of proposed changes in build process. -Ales Ken Frank wrote: > FYI and to see if you have any comments or ideas for implementing this > for next release. > > Thanks - Ken > > > ------------- Begin Forwarded Message ------------- > > Date: Fri, 14 Jun 2002 15:15:37 +0900 > From: Keiichi Oono <keiichi.oono@japan.sun.com> > X-Accept-Language: ja > MIME-Version: 1.0 > To: Ming Dong <mingd@mpkmail.Eng.Sun.COM> > CC: Nancy.Ireland@eng.sun.com, ffj-l10n@eng.sun.com, Mari.Takahashi@Sun.COM, > Ming.Dong@eng.sun.com, Prabhat.Hegde@eng.sun.com > Subject: Re: NBM localization and Update Center > Content-Transfer-Encoding: 7bit > > Thank you Ming and Mari, > > Ming, > The current info.xml is generated automatically from other files > (license, and product message). It is done by build process. So I don't > plan to translate info.xml. I'm going to try to develop tiny script to > generate Japanese info.xml automatically by using existing translated > license and product message. What I need to translate is only netbeans > license information. As you mentioned, I translate it without legal > reviewing. > > You said: > >>>>Let me find out if the info.xml should be sent to RE or kathy. RE is >>> > expected > >>>>to build the localized nbms. Kathy will ten post them on Update center. >>> > > I think current build process does not support to build nbm with > localized info.xml. We need to develop i18n/l10n mechanism to build > localized nbms. > So if it's difficult to localize Update Center by sending info.xml > instead of nbms, I would like to propose to localize them at next > release. > > If it's not correct, please correct me: > - The current nbm does not support localized info.xml. > - The current build process does not support to build with localized > info.xml, because nbm itself does not support. > > To make multi-language nbm, I'm guessing that we need to make: > - define the name of localized info.xml (info_ja.xml ??) > Or define the format of info.xml to includes multi-language > information. > - define the structure of nbm contents. > current: > example.nbm > | > |-Info > | |- info.xml > | > : > > new (as an idea): > example.nbm > | > |-Info > | |- info.xml > | |- info_ja.xml > : (Or should we make locale/info_ja.xml?) > > - make the build process according to the above information. > > Please give me your any suggestions or questions. > > Thank you. > Keiichi > > ------------- End Forwarded Message ------------- > > ========================================================== email #2 Date: Mon, 17 Jun 2002 09:29:44 -0400 From: Jesse Glick <Jesse.Glick@Sun.COM> Subject: Re: NBM localization and Update Center To: Ales Kemr <ales.kemr@Sun.COM> Cc: Ken Frank <Ken.Frank@Sun.COM>, ffj-iteam-uc@Sun.COM, Michal Zlamal <michal.zlamal@Sun.COM> MIME-version: 1.0 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 Ales Kemr wrote: > I vote for following structure and naming (to be consistent with other > localized files): > example.nbm > | > |-Info > | |- info.xml > | |- locale > | |- info_ja.xml Sounds like a good start. But what if localizers wish to release a localized NBM later, after an English NBM has been released? Possibilities: 1. NBM format permits a separate "localized NBM" with localized resources 2. NBM format includes both locales; new version of NBM has new localizations; all users are offered the new NBM 3. As in #2, but the "differential update" feature for AU is implemented, so that the extra downloaded files are only the localized resources, not the base module It would be great to see a complete proposal posted for how localization and AU should work together. #1 above seems the most likely option. I guess Maxym's workaround system, with fake modules for localizations, is closest to it. > CCing Michal and Jesse because of proposed changes in build process. Sure, for example the above structure and naming could be done automatically by <makenbm> I think. What about the update description sent to the client before download? How would that be localized? -Jesse -- Jesse Glick <mailto:jesse.glick@sun.com> x22801 NetBeans, Open APIs <http://www.netbeans.org/> Date: Mon, 17 Jun 2002 09:29:44 -0400 From: Jesse Glick <Jesse.Glick@Sun.COM> Subject: Re: NBM localization and Update Center To: Ales Kemr <ales.kemr@Sun.COM> Cc: Ken Frank <Ken.Frank@Sun.COM>, ffj-iteam-uc@Sun.COM, Michal Zlamal <michal.zlamal@Sun.COM> MIME-version: 1.0 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 Ales Kemr wrote: > I vote for following structure and naming (to be consistent with other > localized files): > example.nbm > | > |-Info > | |- info.xml > | |- locale > | |- info_ja.xml Sounds like a good start. But what if localizers wish to release a localized NBM later, after an English NBM has been released? Possibilities: 1. NBM format permits a separate "localized NBM" with localized resources 2. NBM format includes both locales; new version of NBM has new localizations; all users are offered the new NBM 3. As in #2, but the "differential update" feature for AU is implemented, so that the extra downloaded files are only the localized resources, not the base module It would be great to see a complete proposal posted for how localization and AU should work together. #1 above seems the most likely option. I guess Maxym's workaround system, with fake modules for localizations, is closest to it. > CCing Michal and Jesse because of proposed changes in build process. Sure, for example the above structure and naming could be done automatically by <makenbm> I think. What about the update description sent to the client before download? How would that be localized? -Jesse -- Jesse Glick <mailto:jesse.glick@sun.com> x22801 NetBeans, Open APIs <http://www.netbeans.org/>
Probable duplicate of issue #22948?
I don't think so. This issue is just about recognizing proper info.xml, if there are more than one in the nbm. But I agree, both issues should be solved together.
Target milestone was changed from '3.4' to TBD.
Implemented in trunk AU looks for Info/locale/info_xx.xml (for locale lang xx) at first, then for Info/info.xml
Info/locale/info_*.xml within the NBM, I guess you mean. What about within the server XML file? Trying to think of what the complete usage will be, from 1. Building base module. 2. Building localized NBMs. 3. Publishing server XMLs mentioning both. 4. Client running in non-default locale finds existence of localized NBMs. 5. Client downloads & installs localized NBMs.
> What about within the server XML file? Server XML file should be sent straight in localized form. Value of used Locale is sent to server as parameter (as S1S Update Center use it). However, I agree there should be support for build process.
"Server XML file should be sent straight in localized form. Value of used Locale is sent to server as parameter (as S1S Update Center use it)." - OK, makes sense for S1S I think, but maybe problematic for NB or for any small, third-party update servers, I think. If you need to use a special update protocol to send the locale, this requires a servlet, not just static XML. Even if you encode the locale as part of the URL, you still need a servlet: maybe some user in Hungary is sending http://www.netbeans.org/updates/40_1.5_stable_hu_HU.xml (or whatever). Obviously this file will not exist if there is no Hungarian translation; you want to get the English file. The AU client could retry in a base locale, of course, if it gets a 404 from the HTTP request. What do you suggest?
I think simple perl/cgi could solve instead of servlet. I don't know about good solution for static XML - instead of packing all l10n versions in one big xml :-( Maybe list of available locals can be an attribute of UC (AutoupdateType)? Then AU could try {url}_xx.xml and probably it succeed. If not (404), try {url}.xml
Is this fixed now in context of new chinese localization and need for quantum server to recognize underscores so that zh_CN and zh_TW are treated differently if only localized nbm for zh_CN ? (this is coming in next quantum) If this is fixed now, could someone summarize fix so I can test it using UC ? ken.frank@sun.com