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.
The property sheet shows help text at the bottom when a binding attribute (ex: soap:address) is selected. These documentation are defined in binding schema file using annotation: ex: <xs:element name="address" type="soap:tAddress" > <xs:annotation> <xs:documentation> "address" indicates a address of a soap protocol based service. </xs:documentation> </xs:annotation> </xs:element> We need ability to localize these text.
This is now fixed. The localized value can be provided by adding another documentation for each locale and specifying xml:lang for the language. ex: <xs:element name="address" type="soap:tAddress" > <xs:annotation> <xs:documentation> "address" indicates a address of a soap protocol based service. </xs:documentation> </xs:annotation> <xs:documentation xml:lang="ja-JP"> Japanese text here. "address" indicates a address of a soap protocol based service. </xs:documentation> </xs:annotation> </xs:element> the format of xml:lang is similar to java.util.Locale. It is : language-country-variant. see the documentation for java.util.Locale language maps to getLanguage on current Locale. country maps to getCountry on current Locale. variant maps to getVariant on current Locale. localizing xsd is easiest approach and portable across different solutions. The problem of making xsd invalid can be taken care by making sure you run check xml action on schema in xsd editor. All the binding xsds in different modules in enterprise/wsdlextensions can be localized using above. (Ask Alex Fund if you do not know) Also I eariler added Junit tests in each of these binding extension modules (run as part of entpack build, see unit test in build report http://buildtraq.sfbay/buildtraq/buildgrid.ctrl?project=oriondev&codeline=gavotte&buildType=CB&time=1) which validates xsd files so there is not question of making xsd invalid and not catching it.
Our requirement is that translations are done by translating Bundle.properties files, not xml or xsl or xsd files. Reasons for this was mentioned in comments to other related issues and separate mails. Will these be in Bundle.propeties files ? If not, this needs to be reopened until implementation is done so that Bundle.properties will be read to get these values. ken.frank@sun.com
am reopening since its not clear if this is about messages or info to user while using the functionality or for their own applications in providing translations within their applications ? (there was previous question about this in issue comments below) if its for users own use, then this can be closed again - and could this be added to help - it looks like a helpful piece of information. if its for msgs user sees while using module functionality, then those msgs need to come from bundle files. ken.frank@sun.com
it is for users, and will be seen in the property sheet description.
tested and verified using gfesb 11/03 veerified it on the propertysheet, when clicking on the node or each attribute in the property sheet. At the bottom of the property sheet table, there is a description.