Phil

.. is it worth the effort to have all messages in this command-line suite be separated out into a message catalog?

My experience in dealing with developers in India (i.e., with a very biased sample with respect to the entire population) is that English is a non-issue. I have no experience with working with developers in China (from, but not in).

Extracting messages into a catalog isn't too big a deal. It's one of those problems you just throw time at. Getting those messages translated (and the translations checked), can be a large, long, frustrating undertaking, even for large enterprises that do it on an ongoing basis. You either have to impose early "language change" freezes so that translations can all be done at once, or you stagger releases as translations become available. Neither is fun.

I'd run the question by your product manager. Not phrased as "should we do this?", which just invites a "Yes!", but phrased as "If we do this, it'll cost us X$ to do the message catalog, and Y$ (where Y might be "unknown, and we'll need outside help") to get the translations done. Where should that fit on the list of priorities?"

I'd say that it depends very much on where you are in the project and what time pressures exist on the current development. Also, how likely is the need?

If you are at the beginning/design phase of the project, make finding/designing your i18n library he immediate priority, remembering that simple is best, and have your developers get used to specifying text in terms of message numbers and using the appropriate apis for outputting them etc., from the get go.

If your project is well along, under time pressure or in the mintainance phase, realise that conversion to i18n is a major undertaking, and defer it for a major release. Fork your codebase and run the i18n refactor in parallel to the main thread with one senior developer and as many juniors as you can spare/get budget for. Only merge it back to your main thread once you have a good idea of what the effects and costs are going to be and how much change is going to be required.

If the requirement is only speculative, still do the fork and put a senior developer in charge, but have him consentrate on costing the change rather than doing it, with a view to presenting the speculating management with some hard, profit/costs-based information upon which to base a decision.

Not knowing too much about your specs, I'd lean towards "Yes, have a structured message system."

For one, it's really not that difficult before-the-fact. It can be much more expensive to implement if you change your mind and do it later. Also, it should be much easier to standardize and control the message delivery, (formatting, tense, tone-of-speech, etc.).

Finally, I think it would be easier to test. One of my pet peeves is when a project has the capability to issue messages that aren't to be found in the docs. If the messages are structured, you'll be able to more easily ensure that they're all documented correctly.

I just can't really see much downside to doing it 'right'. Who ever regretted that?

In the web world the most common way to separate interface from logic is via a model-view-controller architecture (MVC). You didn't give us enough information to guess whether that would be directly applicable to your app, but anything you can do to make your code interface-agnostic will help you when it comes time to make cosmetic changes, i18n changes included.

-sam

Well, I meant Indian computer geeks. The kind that have lectured me on both Linux kernel memory management and Iyengar Yoga. I didn't mean the street-sweeper Indians we learned about in social studies in high school.

UPDATE: The truth is often not politically-correct.

Since it may be used in China, I think it would be worthwhile to use the message catalogue, even if the only language required now is English.

The learning experience may also be useful for a future project which will be required to be multi-lingual, too.