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.
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
*** Issue 22947 has been marked as a duplicate of this issue. ***
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!
Will be solved as a part of "Deliver not only modules" feature. *** This issue has been marked as a duplicate of 23445 ***
Reopen, lets solve l10n problem separately
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.
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?
> 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.
Agreed, this sounds good to me.
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
Created attachment 7617 [details] Suggested diff for autoupdate-info.dtd
Created attachment 7618 [details] Example of info.xml used for ml10n
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?
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.
I agree with all of your suggestions, thanks! :-)
"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?
> "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.
OK - just small note: only OpenIDE-Module-Name and OpenIDE-Module-Long-Description are used in AU.
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.
Created attachment 7706 [details] html_ja.nbm - example of ml10n
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?)
> > - 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
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)
reassigne to Hrebejk, new owner of autupdate
Jerry Huth is working on build support, so I'm marking this issue as FIXED.
I presume 3.5 was the correct milestone, not 4.0.