Bug 22948 - [l10n feature] Autoupdate should handle localization
[l10n feature] Autoupdate should handle localization
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Autoupdate
3.x
PC Windows ME/2000
: P2 (vote)
: 3.x
Assigned To: Petr Hrebejk
issues@platform
: I18N
: 22947 (view as bug list)
Depends on: 27756 28770 33095 33096 33097
Blocks: 22944
  Show dependency treegraph
 
Reported: 2002-04-30 06:43 UTC by _ mihmax
Modified: 2003-04-04 21:30 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Suggested diff for autoupdate-info.dtd (1.57 KB, patch)
2002-10-08 10:36 UTC, akemr
Details | Diff
Example of info.xml used for ml10n (1.22 KB, text/plain)
2002-10-08 10:38 UTC, akemr
Details
html_ja.nbm - example of ml10n (2.60 KB, application/octet-stream)
2002-10-18 13:50 UTC, akemr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ mihmax 2002-04-30 06:43:02 UTC
There's currently no way to deploy localized versions of 
modules to the users.

So, I'm asking to do it by AutoUpdate - 
 Let AU detect that there exist a localization of module 
autoupdate, it check that module autoupdate is installed, 
and there should be one more folder "Localizations", where 
appears folder "Russian", and there we see "Autoupdate 
Center l10n".

This could be real just today, autoupdate module, as well 
as a core, are already l10ized, see 
http://translatedfiles.netbeans.org
Comment 1 _ mihmax 2002-04-30 06:45:58 UTC
*** Issue 22947 has been marked as a duplicate of this issue. ***
Comment 2 _ mihmax 2002-05-08 16:30:02 UTC
I requested a developer role in AU to be able to handle it 
myself, and I need help in making it real in Netbeans 3.4!
Comment 3 akemr 2002-08-01 08:31:07 UTC
Will be solved as a part of "Deliver not only modules" feature.

*** This issue has been marked as a duplicate of 23445 ***
Comment 4 akemr 2002-10-03 09:06:59 UTC
Reopen, lets solve l10n problem separately
Comment 5 akemr 2002-10-03 10:10:47 UTC
So, there is my first kick-off:

1. Localization of module (Ml10n) is determined by:
- module codename
- module specification version
- language code

2. update_tracking.xml
Information about currently installed Ml10n's is included in
update_tracking.xml
Let's say module M has /modules/m.jar. You can find in
update_tracking.xml:
- if exists /modules/locale/m_xx.jar
- spec.version of (together installed) module

Structure of update_tracking.xml should be enhanced to allow
save spec. version for newly updated ml10n's
<file name="modules/locale/ant_ja.jar" 
      crc="3039487722"
      locale="ja"
      specification_version="2.0.3" />

3. Nbm of ml10n without module
There should be special structure for info.xml with attributes:
  module name
  module codename
  module spec. version
  language code
  description
  
There should be build support to create m_xx.nbm

4. Visibility on Update Center
Ml10n (lang xx) will be visible on UC if module is installed and has
no l10n_xx or has l10n_xx with lower spec.version

5. Deleting unused files
IMHO I should reappraise #26213 - AU should not delete l10n files
(/locale/m_xx.jar), even if they are not included in upgraded module nbm.
Comment 6 _ mihmax 2002-10-03 10:40:18 UTC
Totally agreed!

but some questions:
> - module specification version

Should l10n of a module then depend on a certain module version?

> There should be build support to create m_xx.nbm
see task # 27756

> 4. Visibility on Update Center
Is it possible to give user an option to automatically download all
localizations of the modules he has?
Comment 7 akemr 2002-10-03 10:56:10 UTC
> Should l10n of a module then depend on a certain module
> version?

I don't think so. This attribute means - l10n was created for this
spec. version. Just to allow upgrading of newer versions of Ml10n.

> Is it possible to give user an option to automatically 
> download all localizations of the modules he has?

Automatically? Don't know. Standard AU wizard procedure could be
sufficient. However there could be possible options like:
- show localizations
- show only localizations
- show only locale xx / my locale
.. but this part can be solved consecutively.
Comment 8 Jesse Glick 2002-10-03 15:21:24 UTC
Agreed, this sounds good to me.
Comment 9 akemr 2002-10-08 10:35:04 UTC
I'll attach my suggested diff to info.xml dtd, allowing to distribute
standalone ml10n (and example of such info.xml)

Differences:
- l10npackonly attribute (true for ml10n, otherwise false)
- l10n element presented for ml10n
- manifest element missing for ml10n
Comment 10 akemr 2002-10-08 10:36:23 UTC
Created attachment 7617 [details]
Suggested diff for autoupdate-info.dtd
Comment 11 akemr 2002-10-08 10:38:15 UTC
Created attachment 7618 [details]
Example of info.xml used for ml10n
Comment 12 Jesse Glick 2002-10-08 14:53:02 UTC
Looks pretty good so far. Suggestions:

1. Make a new public ID, i.e. a new DTD rather than changing the old
one. Be sure to update /xml/entities/ in layer, and www/www/dtds/catalog.

2. <module> element contents might more naturally read:

<!ELEMENT module (description?, module_notification?,
external_package*, (manifest | l10n), license?)>

i.e. you need either a manifest or L10N decl, but not both.

3. l10npackonly attr seems redundant if you have a l10n element anyway.

4. Is module_spec_version enough? Do you need the major release
version of the module (if any)? <module codenamebase="..." ...> does
not give it for regular NBMs but <manifest OpenIDE-Module="..." ...>
does. However if you have only a <l10n> child element then there is
nothing giving the major release version (which is optional). I
suggest perhaps:

<!ATTLIST l10n   langcode             CDATA #REQUIRED
                 module_spec_version  CDATA #IMPLIED
                 module_major_version CDATA #IMPLIED
                 description          CDATA #IMPLIED>

(note that spec versions are also optional, though I don't know if AU
can even work at all without them)

5. I assume this system should be usable for branding NBMs too. In
that case I would suggest

<!ATTLIST l10n   langcode             CDATA #IMPLIED
                 brandingcode         CDATA #IMPLIED
                 module_spec_version  CDATA #IMPLIED
                 module_major_version CDATA #IMPLIED
                 description          CDATA #IMPLIED>

i.e. you can have either langcode, or brandingcode, or both:

<l10n langcode="ja"
      brandingcode="f4j"
      module_spec_version="1.0.2"
      module_major_version="1"
      description="S1S Japanese localization for Classfile Reader
module"/>

6. description attr on l10n: is the description supposed to be in
English? Or the target locale? Is this field even necessary?
Comment 13 _ mihmax 2002-10-08 15:07:31 UTC
my 2 copeecs:
> 6. description attr on l10n: is the description supposed 
> to be in English? Or the target locale? 

If it will be, then both

>Is this field even necessary?

Maybe not, maybe AU center should create a description on-the-fly,
consisting from: The localized module desc, & The locale user-friendly
name.

Comment 14 akemr 2002-10-08 15:19:23 UTC
I agree with all of your suggestions, thanks! :-)
Comment 15 Jesse Glick 2002-10-08 15:26:08 UTC
"Maybe not, maybe AU center should create a description on-the-fly,
consisting from: The localized module desc, & The locale 
user-friendly name." - ah, problem. If you have yet downloaded the
L10N for a module, there is no module display name or long description
in your native locale yet. That information must be made available in
the update description XML.

Suggestion: <l10n> element could include the localizable header
attributes from <manifest>, where these would be assumed to be in the
target locale, thus:

<l10n langcode="cs" OpenIDE-Module-Name="Ctenarek klasovych souboru" 
OpenIDE-Module-Short-Description="Cte klasove soubory."
OpenIDE-Module-Long-Description="Cte klasove soubory, tak co dal
chcete vedet?" OpenIDE-Module-Display-Category="Javove pomucky"
module_spec_version="1.5" module_major_version="1"/>

Any localizable attributes which are missing would be inherited from
the base locale (or more commonly, from the null branding, if this is
a branded NBM). It is assumed you already have the base-locale NBM
installed, or it is available on the same update server.

Does that work?
Comment 16 _ mihmax 2002-10-08 16:03:44 UTC
> "maybe AU center should create a description on-the-fly"
> - ah, problem. 
> Does that work?

Yes, I missed the thing, and thus this info must be in XML, I see no
other way.
Comment 17 akemr 2002-10-09 08:33:43 UTC
OK - just small note: only OpenIDE-Module-Name and
OpenIDE-Module-Long-Description are used in AU.
Comment 18 akemr 2002-10-18 13:48:29 UTC
Most of work commited in trunk. Currently it's possible to update l10n
nbm's.

What remains:
- change nbbuild/..../MakeNBM.java, MakeUpdateDesc.java
  to work with new DTD's
- support for building l10n nbm's

I'll attach example of l10n-nbm for html module.
Comment 19 akemr 2002-10-18 13:50:26 UTC
Created attachment 7706 [details]
html_ja.nbm - example of ml10n
Comment 20 _ mihmax 2002-10-18 21:23:26 UTC
Looks good.

> - support for building l10n nbm's
Yeap, what changes are necessary?

I think it goes to 4.0, what's the schedule for 4.0 (when should
we@translatedfiles change out behaiviuor?)
Comment 21 akemr 2002-10-21 09:41:19 UTC
> > - support for building l10n nbm's
> Yeap, what changes are necessary?

This is actually my task. Probably MakeNBM should be changed to allow
create info.xml in new format. I'll consult it with Michal Zlamal.

> when should we@translatedfiles change out behaviuor?

After I'll mark this issue FIXED. Currently you can manually create
somemodule_ru.nbm and test this feature - it will be really welcome :-)
it 

Comment 22 akemr 2002-11-15 09:20:05 UTC
I increased AU internal specification version to 1.6 after
implementing this feature => 
new AU will check URL http://www.netbeans.org/updates/dev_1.6_.xml
(and beta, alpha..) for updates and all newly builded nbm's (including
possible localized ml10n..) will be uploaded to this URL (not the old
*1.5_.xml)
Comment 23 Marian Mirilovic 2002-12-06 18:50:20 UTC
reassigne to Hrebejk, new owner of autupdate 
Comment 24 akemr 2003-01-10 08:29:39 UTC
Jerry Huth is working on build support, so I'm marking this issue as
FIXED.
Comment 25 Jesse Glick 2003-04-04 21:30:38 UTC
I presume 3.5 was the correct milestone, not 4.0.


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