db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
Date Wed, 01 Nov 2006 23:19:56 GMT
    [ 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/%3c44F62247.2080500@apache.org%3e
> 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

        

Mime
View raw message