Dennis,
I just took a look at your plugin. Good stuff! Didn't try it, but the
report it looks like it can generate seems like it would be really
useful for those i18n'ing an app (missing/extra keys, messages that
aren't different- although obviously the latter would be ignored in
cases where the message should be the same (en_US vs. en_GB being a good
example of a place where you might want to have it show which other
locales it it shares the message(s) with). And the pseudo-localization
stuff seems like it would be helpful also (my needs for messing with
i18n so far have been to allow others to provide translations of the
code I've written rather than to translate it myself, with the exception
of needing to translate from en_GB to en_US (not a huge task, but big
enough that I wrote code to do it) and needing to use localization for
re-branding of Confluence (change everywhere it says "Confluence" to
"DukeWiki", change "contact your administrator" to "contact helpdesk
at"... etc.
I would be happy to join forces, but my concerns would be:
1) Scope
* Stuff I was doing in i18nsanity was outside the scope of a plain maven
mojo (also providing command-line and ant tasks). Not sure best way to
split it out/refactor it.
2) Time
* I have even less time now that I've had in the past to work on
consolidation of projects because a senior dev is leaving from our team
and I have to pick up the slack.
* The main reasons I wanted to contribute the i18nsanity plugin to
codehaus were to make it easy for others to use and to be able to use it
in a project I was contributing to the Atlassian community, and now it
looks like Atlassian might host the i18nsanity plugin for the meantime
which negates the need for the latter. However, as long as I could just
dump the code into your plugin and you manage it from then out, it might
work (this would probably mean abandoning the sourceforge project
though, and maybe someone would have found the CLI or Ant tasks handy...
:( again, it would be great if sourceforge had a maven2 repository so we
could just place a dependency on it or a library that common
functionality could be refactored into that was hosted there).
3) Naming (a.k.a. stupid anal-retentive concerns)
* neither i18sanity-pt nor l10n-maven-plugin quite capture what both of
these libraries together would accomplish (I wish that there was a
single term for i18n/l10n to use, and the i18sanity stuff can do work
with properties files totally independently from i18n/l10n, so maybe
they should be refactored into a separate library.
* i18sanity has a cool name (tough to let it go) :) ! (I think l10n
looks like "lion" too... probably some awful name could arise from those
two put together)
Let me know what you think or we can discuss offline...
Gary
Dennis Lundberg wrote:
Hi Gary
This sounds interesting. Could you have a look at the l10n-plugin
that we have in the sandbox. Perhaps these two can combine forces?
https://svn.codehaus.org/mojo/trunk/sandbox/l10n-maven-plugin/
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
