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.

Bug 98893

Summary: I18N - use translatedfiles to prepare translated info.xml files during ml nbms build
Product: www Reporter: Ken Frank <kfrank>
Component: Builds & RepositoriesAssignee: rbalada <rbalada>
Status: RESOLVED FIXED    
Severity: blocker CC: jrechtacek, keiichio, krajeswaran, masaki, wzhang
Priority: P2 Keywords: I18N
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 118390    

Description Ken Frank 2007-03-25 17:10:27 UTC
I realize this is not completely an RE activity and want to get your feedback
on how/where to communicate about the other parts.

This is based on long time request from l10n team.

- they need to translate info.xml for uc modules; not sure if they need to do it
for all modules

- but info.xml is not in l10n kits so they need to get, in the large nbms file,
the info.xml of each module they need to translate for

then they need to send by mail to RE the translated file

REQUEST:

1. have the info.xml in nb cvs so it can be added to l10n.list of each applicable
module (or l10n.list.uc) so then it will be in the regular or uc l10n kit.

2. they will putback the info.xml to translatedfiles/src - so that RE can use that
info.xml in the building of the ml nbms.

QUESTION

for #1, is it technically possible for the info.xml to go to nb cvs ?

if so, then I think that dev needs to add it to l10n.list or l10n.list.uc

BTW, where do the info.xml files live ? is it in a cvs, or are they dynamically
created from a template when a given nbm is built ?

ALTERNATE IDEA ?

there is one large nbm file in the builds - if one had a list of the names
of each nbm that needed to have info.xml localized, a script could
extract the info.xml for each and to a directory.

But there would be a namespace collision since all info.xml are in
Info/info.xml.

But perhaps the directory name could be the basename of each nbm,
so that each info.xml would go in a unique location.

then these files could be provided as a special kit, and then putback to
translatedfiles in the same structure, and used for building the ml nbms ?
Comment 1 Keiichi Oono 2007-03-26 06:09:57 UTC
Please allow me add a comment. I'm always delivering translated info.xml for UC
releases, but I'm not doing the translation. Because all the strings in that xml
are contained message resource files Bundle.properties.
What I always do is:
  1. Pick up appropriate strings from Bundle_ja.properties or
Bundle_$locale.properties for other locales
  2. replace English string with the above string
  3. license information is English in recent releases

I don't think we have to use CVS and l10n-kit for info.xml localization. English
info.xml is always generated from MakeNBM ant task in the build script, so I
would like to request to generate localized info.xml (e.g. info_ja.xml,
info_zh_CN.xml) from MakeNBM ant task as same as English xml.

Please see another issue for the autoupdate:
http://www.netbeans.org/issues/show_bug.cgi?id=58118

Since autoupdate has been fixed to support localized info.xml, I guess the
following tasks can be automated:
  - Generate localized info.xml
  - re-package NBMs with the localized info.xml

Would you give your any thoughts?
Comment 2 Ken Frank 2007-03-26 06:34:35 UTC
I filed this based on feedback over the years from various members
of translation team as well as recent feedback from your project management.

Can I ask that translation team discuss among yourselves to see if its still
something that is wanted (info,xml in kits and related processes) - its not about
anything else.

Please let me know in some separate mails since base team should not spend time
doing this if its not
important to have; it was communicated to me in past that it was important to have,

ken.frank@sun.com
Comment 3 Karthikeyan Rajeswaran 2007-03-26 07:23:30 UTC
As per keiichio, all the information that is required for building an info.xmml
are already part of the workspace and also part of l10n kit. Therefore, the
repository/kit issue, which used to exist, seems to have been resolved by itself
over time.

There are still two issues that need to be addressed:
- Even though all the individual pieces of data are available, localized
info.xml files themlseves are still not prepared by the build script. This
forces the l10n teams to prepare them manually and to store the generated
info.xml files on their servers for later reference. As keiichio has mentioned,
this problem can be solved if MakeNBM is modified to produce localized info.xml
automatically.

- Once the localized info.xml files are present, the question is how should the
nbms be produced?
1. A single nbm can be produced with all the info.xml files. Since au client now
supports multiple info.xml files in a single nbm, this should work.
2. Prepare a separate nbm for each locale with code+lang_bundles+lang_info_xml.
3. Prepare a separate nbm for each locale but only with
lang_bundles+lang_info_xml. Then we can use the process outlined in
http://platform.netbeans.org/articles/how-to-do-localization.html.

I think we should file a separate RFE to discuss both the above issues. Pl.
inform if you agree and i will file a new RFE.
Comment 4 Ken Frank 2007-03-26 08:17:50 UTC
I don't recall seeing info.xml in l10n kits and I don't recall seeing them
in l10n.lists  and thus localized nbms wont be built from using the info.xml
translated files put back into translatedfiles --  and all that is the context
of this issue. I realize that
getting the info.xml into the cvs and into the lists is activitiy of developers
but this issue is about initiating that activity to happen, not from filing
separate issues on each module but a unified approach with dev team leadership.

Can we keep discussion of the above items to this issue as filed ?

For the other things mentioned, I do suggest filing a separate issue(s)

ken.frank@sun.com
Comment 5 rbalada 2007-04-17 16:19:48 UTC
There is alternate idea.

First of all I have to say that the info.xml file is *generated file* and thus
is not supposed to be part of L10Nkit. Don't get sad, there's a solution.

It's generated from some properties file. It's very likely that such a
"Localizing-Bundle" is regular part of L10Nkit and thus translated and available
somewhere in translatedfiles/src. I've also heard there's possibility to have
Info/info_${locale}.xml inside of NBM file. 

So the alternate idea is to utilize the information described above and generate
ML NBMs with multiple translated info.xml files by default.

Moving to RE queue for further re-assignments.
Comment 6 rbalada 2007-04-17 16:33:48 UTC
Changing from DEFECT to ENHANCEMENT. Targeting to Milestone 11 for now.
Comment 7 Karthikeyan Rajeswaran 2007-04-17 18:21:31 UTC
As an alternative to producing ML nbms with multiple jars and info.xml files,
have you considered building individual ML nbms each targeting a language, as
described in http://platform.netbeans.org/articles/how-to-do-localization.html ?
Comment 8 rbalada 2007-09-27 21:05:10 UTC
Reassigning to me.
Comment 9 rbalada 2007-10-11 22:48:23 UTC
Checking in nbbuild/antsrc/org/netbeans/nbbuild/MakeNBM.java;
/cvs/nbbuild/antsrc/org/netbeans/nbbuild/MakeNBM.java,v  <--  MakeNBM.java
new revision: 1.78; previous revision: 1.77
done
Comment 10 Jesse Glick 2007-10-12 01:07:40 UTC
<makenbm> is used in the external build harness. Will this patch have any effect on existing build scripts? It is too
large for me to follow what it is doing.
Comment 11 rbalada 2007-10-12 14:32:32 UTC
Jesse,

it should be safe for external build harnesses. 

I'm sorry if following description is cryptic, feel free to ask for further explanation.

The change has added support to allow <makenbm locales="${locales}"/> attribute and the task now reads
OpenIDE-Module-Localizing-Bundle manifest value and tries to locate localized versions of that bundle in localized
module jarfile(s). For example you can have module jarfile "modules/org-foo-bar.jar" with localizing Bundle
"org/foo/bar/Bundle.properties" and some localized jarfiles in "modules/locale/org-foo-bar_${locale}.jar", which contain
"org/foo/bar/Bundle_${locale}.properties" files (each localized jarfile can have one localized localizing bundle file.
These localized jarfiles are checked for existence of such localized localizing bundle and if found, their values are
used for creation of localized info.xml file in Info/locale/info_${locale}.xml file. These localized info.xml files are
then added to NBM.