Hi! I'm a happy inFocus customer and obviously eager to test the new and updated release of inFocus as soon as it's available.
In my work, I tend to do a lot of non-English sites, and even sometimes some multilingual sites, using the fantastic WPML plugin (combined with Dynamic Widgets, you can do pure magic to support multilingual sites). In my very early days with WordPress (around 2005 or so...), I did patiently translate all PHP files manually, and became insanely frustrated when a theme upgrade would hopelessly trash all my weeks of work...
Then WordPress fortunately became more internationalized. By surrounding all strings with __(...) or _e(...), theme and plugin designers could simply make them "translation-ready" without needing to actually support multiple languages from scratch. Translators can follow a set of simple guidelines to "extract" all the strings, translate them, and place a POT file on the root directory of the theme. WordPress will do all the magic by reading the WP_LANG constant on wp-config.php and just load for all themes and plugins the appropriate POT file, if it's present; if not, well, it just reverts to English (Plugins like WPML just check if all required POT files for all languages are present and switch that on demand).
For the theme designers, not much extra work is required. If you start from scratch placing all strings enclosed by __(...) or _e(...), it really doesn't take much long. Translators, thanks to automated tools, can extract all strings in seconds instead of patiently going manually through all files, one by one, and change the translations. WordPress itself works like this. The beauty of the system is that themes/plugins can safely be upgraded and nothing will ever be broken: the worst that can happen is that an upgrade might have some extra strings to be translated, but the "outdated" POT file will at least be valuable to translate most of it. Theme/plugin developers don't even need to support/maintain different languages; they can worry only about supporting English, but give translators the opportunity to add languages on their own (and share them with the community!) independently.
Just by embedding those functions is enough for many. For instance, popular words like "Name", "Edit", "Post", "Submit" and so forth are already translated by WordPress itself, and so, something like _e('Edit'); would automagically be translated even without a theme-specific POT file. Since many theme developers use frameworks and snippets of code from each other, the probability that a lot of the major keywords get automatically translated without any effort is actually quite high!
Needless to say, practically every theme or plugin I've come across in the past 3 years uses this approach.
inFocus is sadly a notorious exception.
As can be seen from this thread on translation issues there are a lot of strings to translate. For the MySiteMyWay theme developers, it means a lot of extra work just to go through everything and manually add the required __(...) or _e(...); with the latest inFocus release already a bit late, I can understand that this might be too much to ask. Also, although inFocus remains a popular choice, I have no idea how many people actually use it on different languages, but there are certainly a few of us. But at least inFocus would be future-proof. Next releases would have the developers just automatically adding the required additional strings with the required tags, and, well, it's just 4 extra characters to type — not much work, if it's done from scratch.
And all users of international sites would just love the flexibility even more :)
A side-effect of "thinking international" is dealing with dates. WordPress allows blog/site owners to set their date format from popular choices on the admin panel (you might not be aware of that, but if you switch the language of WordPress, it will display a different set of choices for dates which is more appropriate for the country where that language is spoken — Automattic is very clever!). However, I understand that very early WordPress versions (I've just started using WP on version 1.5, and don't remember how it worked back then) didn't support this, and, worse, most blog owners didn't bother to actually configure the dates properly, so almost all themes (and plugins), from then on, have "forced" the date by default on their code, usually (but not always) using the American date format.
Also, for years the the_date() function, which would retrieve the date with the current WP settings, was sort of broken: it just retrieved the date for the first post on the Loop (there was some logic to this). Since WP 3.0, however, we have at least two new functions to deal with internationalization: echo get_the_date(); will work fine (on all posts on the Loop), and allegedly echo date_i18n(); is even present since WP 0.71 although I've never seen it used.
The alternative, which I have seen on some themes, is to place the date format string with embedded tags (e.g. the_date(__('F j, Y'));. While this will still "force" the American date format, and ignore what the WP admin settings say, at least it will allow translators to create their own POT file to replace that string as well. It's a bit awkward, but it certainly works.
I understand that some of the above is due to be released on a future version of inFocus. Yay!
