You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Andrew Jaquith <an...@gmail.com> on 2009/01/14 15:33:48 UTC
New migration tool coming
All--
I got frustrated with the labor intensiveness of moving and renaming
message keys in all of our localized bundles, so I decided to do
something about it. Last night I coded up 'BundleMigrator', which will
copy, move, rename or delete message keys from or between resource
bundles, in bulk.
The core code works beautifully, though there's no interface per se.
Tonight I'll write a command-line interface. Any preferences? I'm
thinking of something like this:
BundleMigrator rename src/i18n/CoreResources error.oldname error.newname
BundleMigrator delete src/i18n/CoreResources error.oldname
BundleMigrator copy src/i18n/CoreResources src/i18n/templates/default
error.oldname
BundleMigrator move src/i18n/CoreResources src/i18n/templates/default
error.oldname
Another consideration: because we also have the ability to parse and
modify JSPs (JSPMigrator), it would also be a fairly simple thing to
add a 'find' command:
BundleMigrator -jsp src/webdocs find error.oldname
...although grep works pretty well for this also.
Thoughts?
Andrew
Re: New migration tool coming
Posted by Andrew R Jaquith <an...@gmail.com>.
Actually, I was planning to support all of those 'verbs,' (rename/
delete/copy/move) because I can see uses for all of them. My question
was really about the syntax -- that is, whether it seemed reasonable.
On Jan 14, 2009, at 12:11 PM, Harry Metske wrote:
> Andrew,
>
> assuming you don't want to have message keys in both locations, I
> would
> think that "move" is the best choice, with the option to specify a
> new name:
>
> BundleMigrator error.oldname error.newname
>
> - this should delete the error.oldname from
> i18n/templates/default*.properties (can you also handle the non-
> ASCII keys
> in the Chinese and Russian version ?)
> - create new key with error.newname in CoreResources*.properties
> (with the
> same value as in the old ones)
> - search in java source and JSP's and change occurrences of
> error.oldname to
> error.newname ?
>
> (or I have not understood the intention of the BundleMigrator off
> course :-)
> )
>
> regards,
> Harry
>
>
> 2009/1/14 Andrew Jaquith <an...@gmail.com>
>
>> All--
>>
>> I got frustrated with the labor intensiveness of moving and renaming
>> message keys in all of our localized bundles, so I decided to do
>> something about it. Last night I coded up 'BundleMigrator', which
>> will
>> copy, move, rename or delete message keys from or between resource
>> bundles, in bulk.
>>
>> The core code works beautifully, though there's no interface per se.
>> Tonight I'll write a command-line interface. Any preferences? I'm
>> thinking of something like this:
>>
>> BundleMigrator rename src/i18n/CoreResources error.oldname
>> error.newname
>> BundleMigrator delete src/i18n/CoreResources error.oldname
>> BundleMigrator copy src/i18n/CoreResources src/i18n/templates/default
>> error.oldname
>> BundleMigrator move src/i18n/CoreResources src/i18n/templates/default
>> error.oldname
>>
>> Another consideration: because we also have the ability to parse and
>> modify JSPs (JSPMigrator), it would also be a fairly simple thing to
>> add a 'find' command:
>>
>> BundleMigrator -jsp src/webdocs find error.oldname
>>
>> ...although grep works pretty well for this also.
>>
>> Thoughts?
>>
>> Andrew
>>
Re: New migration tool coming
Posted by Harry Metske <ha...@gmail.com>.
Andrew,
assuming you don't want to have message keys in both locations, I would
think that "move" is the best choice, with the option to specify a new name:
BundleMigrator error.oldname error.newname
- this should delete the error.oldname from
i18n/templates/default*.properties (can you also handle the non-ASCII keys
in the Chinese and Russian version ?)
- create new key with error.newname in CoreResources*.properties (with the
same value as in the old ones)
- search in java source and JSP's and change occurrences of error.oldname to
error.newname ?
(or I have not understood the intention of the BundleMigrator off course :-)
)
regards,
Harry
2009/1/14 Andrew Jaquith <an...@gmail.com>
> All--
>
> I got frustrated with the labor intensiveness of moving and renaming
> message keys in all of our localized bundles, so I decided to do
> something about it. Last night I coded up 'BundleMigrator', which will
> copy, move, rename or delete message keys from or between resource
> bundles, in bulk.
>
> The core code works beautifully, though there's no interface per se.
> Tonight I'll write a command-line interface. Any preferences? I'm
> thinking of something like this:
>
> BundleMigrator rename src/i18n/CoreResources error.oldname error.newname
> BundleMigrator delete src/i18n/CoreResources error.oldname
> BundleMigrator copy src/i18n/CoreResources src/i18n/templates/default
> error.oldname
> BundleMigrator move src/i18n/CoreResources src/i18n/templates/default
> error.oldname
>
> Another consideration: because we also have the ability to parse and
> modify JSPs (JSPMigrator), it would also be a fairly simple thing to
> add a 'find' command:
>
> BundleMigrator -jsp src/webdocs find error.oldname
>
> ...although grep works pretty well for this also.
>
> Thoughts?
>
> Andrew
>