[ 
http://issues.apache.org/jira/browse/DERBY-1868?page=comments#action_12446401 ] 
            
Rick Hillegas commented on DERBY-1868:
--------------------------------------

Hi David,

Thanks for reviewing this patch. Some responses follow:

1) License headers appeared in the previous, non-generated versions of 
messages_en.properties and rrefexcept71493.dita. I erred on the side of caution 
and included license headers in the generated versions. License headers might 
still make sense for the following reasons:

- messages_en.properties is shipped with the product

- rrefexcept71493, although generated, is still independently checked into the 
source repository

Although they are generated, I could see them being construed as "creative" 
works deserving the license header. I always get muddled around these legal 
issues and am inclined to err on the side of caution. Do you think there is 
some harm done by doing this?

2) I like your suggestion about having translators translate messages.xml and 
have MessageBuilder generate locale-specific versions of rrefexcept71493.dita. 
So, instead of one messages.xml, we could have messages.xml.en, 
messages.xml.ja_JP, etc. It would be helpful to move the boilerplate out of 
MessageBuilder into messages.xml.*. Note that today's shift to xml-based 
descriptors has not increased the translator's burden Yesterday, translators 
still had to tranlate both of the files you mentioned. Your suggestion is a 
great one--but it's someone else's follow-on itch!

> Merge argument descriptors into SQLState strings so that SQLState 
> documentation can be generated by a program
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1868
>                 URL: http://issues.apache.org/jira/browse/DERBY-1868
>             Project: Derby
>          Issue Type: Improvement
>          Components: Build tools
>    Affects Versions: 10.2.1.6
>            Reporter: Rick Hillegas
>         Assigned To: Rick Hillegas
>             Fix For: 10.2.2.0
>
>         Attachments: antlib.diff, derby-1868-lineEndings-v01.diff, 
> derby-1868-merged-v01.diff, derby-1868-merged-v02.diff, messages.dtd, 
> messages.xml
>
>
> See DERBY-1566. That JIRA introduced a program, written by David, which 
> generates human-readable tables of message strings for inclusion in the 
> Reference Guide. The tool doesn't patch in friendly arguments. That leaves 
> the message strings peppered with unfriendly placeholders like {0}. {1}, 
> etc.. Laura painstakingly editted the tables, by hand substituting in 
> friendlier arguments like <userName> and <tableName>.
> We need to move Laura's substitutions into the source code so that David's 
> program can automatically plug them in. This will save us a lot of grief when 
> we generate future releases. Dan and Andrew have proposed approaches to this 
> problem. Those approaches are discussed in DERBY-1566. Here is Andrew's 
> comment on Dan's proposal:
> "While Dan's suggestion here:
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL 
> PROTECTED]
> to generate the message file and doc from a single XML file would be ideal, a 
> simpler approach to implement would be to maintain the meanings of the 
> markers in another properties file, identified by message key and marker 
> number. So, e.g. the new properties file would contain:
> 01500.0=<constraintName>
> 01500.1=<tableName>
> Then ErrorMessageGenerator could look up the value of the markers by SQLState 
> and MessageFormat marker number in the properties file, although this 
> approach would require maintaining two files instead of one."
> I glossed this further: "If we adopt Andrew's approach, I would recommend 
> co-locating the argument descriptiors in the same properties file which 
> contains the messages. This will help keep the argument descriptors from 
> drifting out of sync with the messages themselves--that is a substantial 
> advantage of Dan's approach."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to