Bug 24886 - I18N - allow AU client to recognize proper localized info.xml
I18N - allow AU client to recognize proper localized info.xml
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Autoupdate
-FFJ-
Sun Solaris
: P2 (vote)
: 3.x
Assigned To: akemr
issues@platform
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-17 15:51 UTC by Ken Frank
Modified: 2003-07-22 19:30 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2002-06-17 15:51:37 UTC
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/>
Comment 1 Jesse Glick 2002-06-19 18:14:33 UTC
Probable duplicate of issue #22948?
Comment 2 akemr 2002-06-20 08:02:20 UTC
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.
Comment 3 Marek Grummich 2002-07-22 08:24:39 UTC
Target milestone was changed from '3.4' to TBD.
Comment 4 akemr 2002-09-30 09:25:49 UTC
Implemented in trunk

AU looks for Info/locale/info_xx.xml (for locale lang xx)
at first, then for Info/info.xml
Comment 5 Jesse Glick 2002-10-02 20:31:57 UTC
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.
Comment 6 akemr 2002-10-03 09:13:54 UTC
> 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.
Comment 7 Jesse Glick 2002-10-03 15:19:12 UTC
"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?
Comment 8 akemr 2002-10-04 08:51:40 UTC
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


Comment 9 Ken Frank 2003-07-22 19:30:18 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo