Review request for 7196354 check-in jdk.tbom file to openjdk repo
naoto.sato at oracle.com
Tue Sep 11 05:57:14 UTC 2012
Looks like the list does not reflect the recent changes introduced by
the re-organization of the locale data (sun/util/resources).
To me, just keeping an eye on the files sounds error prone. Would it be
possible to add some automated check, say in "jcheck"?
On 9/10/12 2:26 PM, Michael Fang wrote:
> Hi Mark and all,
> I have updated the webrev:
> It includes the following changes:
> - removed component division and contact names
> - removed redundant "target" attributes
> I am also moving the file from root of source tree to jdk/make/jdk.tbom.
> SGT strongly recommends we follow the standard file naming convention
> used by the translation system, which is component-name.tbom. This is
> followed by all Oracle products requiring translation.
> We currently have no plan to publish the syntax and semantics to the
> openjdk community through JEP process. We would like to keep the syntax
> internal. When I review dev team's changes related to resource files, I
> will keep an eye on the files to be translated and translation language
> Server Globalization Technology
> On 12年09月06日 04:46 下午, Michael Fang wrote:
>> Hi Mark,
>> Thanks for the review and feedback.
>> Please see my comments inline below.
>> On 12年09月06日 01:29 下午, mark.reinhold at oracle.com wrote:
>>> 2012/9/5 14:08 -0700, michael.fang at oracle.com:
>>>> Please help to review the new JDK8 file for the following CR:
>>>> 7196354 check-in jdk.tbom file to openjdk repo
>>>> The webrev is located at:
>>> This file needs a more descriptive name, especially if it's going to be
>>> in the root of the source tree. Suggestion: translated-files.xml .
>> The translation drop system is now an Oracle-wide translation system
>> and we are strongly recommended to follow the standard naming
>> convention for all Oracle products, which is component-name.tbom.
>> I have checked with the team and we can move the file away from the
>> root of the source tree to, for example, jdk/make/jdk.tbom.
>>> Is there a DTD or a schema for this file? I can guess what most of it
>>> means, but I might guess incorrectly.
>> The XSD is available in NLSTOOLS ADE label.
>> It's internal information. I will find it and forward it to you
>>> [line 8] "OpenJDK" isn't a component, it's a community. I think you
>>> "JDK" here.
>> Yes, JDK.
>>> The "JDK" / "JRE" division in this file is somewhat artificial and
>>> to become incorrect over time -- not every developer knows exactly which
>>> files are in the JRE vs. the full JDK. I suggest doing away with that
>>> division and simply sorting the file-set elements by source file name.
>> JDK and JRE are translated into different sets of languages. 2
>> languages for JDK and 10 for JRE. We used to divide the files this way
>> in order to translate the files into the correct set of languages. But
>> it's not necessary now. Sorting by groups or projects may be fine.
>> Whatever is easy for the groups/teams to find and maintain their files.
>>> At a glance it looks like the source and target attributes for any given
>>> file are identical. Do you expect there to be cases where they're
>> In jdk.tbom, source and target are the same for all files. But on
>> jdkclosed.tbom, the man page files have different source and target
>>>> Since the dev team will need to maintain this file in the future
>>>> (modifying it
>>>> if you add or delete resource files), I temporarily put down your
>>>> name as
>>>> contact for the file. Please figure out the proper owner and we can
>>>> update it
>>> We don't put contact names in source code. Please remove my name,
>>> and do
>>> not add another.
>> OK, I will remove it.
>>>> In the future, if any bug/rfe requires adding/deleting resource
>>>> files, the dev
>>>> work should include updating this file to reflect the correct
>>>> resource file
>>>> list. (and please ask me to review it).
>>> If you expect other people to update this file over time then you need
>>> to document that expectation somewhere and, as importantly, you need to
>>> document the syntax and semantics of the file. Fortunately we have a
>>> way to do that, namely the JEP process (http://openjdk.java.net/jeps/).
>>> I suggest you draft a JEP for this and circulate it for review along
>>> with the webrev.
>> I will look into it.
>>> - Mark
More information about the core-libs-dev