I think that this is the best idea thus far - but I'm a little confused. How exactly would I go about releasing DateTime::NaturalLanguages and DateTime::NaturalLanguages::EN with it? Would I just release the two modules (both in english), and then mention in my POD that if anyone wanted to translate it they were free to?
| [reply] |
Release one distribution called DT::NL and have it bundle DT::NL and DT::NL::EN. That will be the default choice, but you might want to look at whatever localization ENV there might be. Or, just let the user set it. DT::NL will create and return a DT::NL::EN - it will be a factory. You mention in the POD for DT::NL that there is a mechanism for providing different languages and point to DT::NL::EN as a reference implementation. Then, you don't do anything else and let people release versions as they see fit. As they do, you will get requests for new features or to reorganize the code in such a way as to make their lives easier. Be responsive and you just created a community around your little module.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Unless the module provides a standard "DateTime" object somehow, it would be confusing to put it under the "DateTime"-namespace.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |