now as James'(i think) new framework is in cvs and we finally know about how it works, i figured it might be a good idea to discuss the long-run viability of the approach.
Disclaimer: it's not that i don't like the current approach, it will do what it's supposed to accomplish, i just feel it's not the best long term solution.
i'd hate to see everybody jumping onboard just to discover later there might have been a better way of doing it.
This btw. is an inherent problem with the - hopefully now superceeded - historic approach to development management, we should have at least some minimal discussion about such important subsystem changes before implementaion starts.
what i propose is to move translation to the template(style) level using a "translate"(name suggestions welcome) smarty plugin + caching backend(reusable for possible other, future template engines) + cascading language files.
translation files should be moved to their respective views(tighter bundling), e.g. to views/lang.
the backend should use the same filename resolution as the rest of exponent(proposal: pathos_core_resolveFile() -> search order: subtheme, theme, maybe theme/common, module, common) to allow drop-in replacement/extension at deployment sites.
- for logical reasons(e.g. simplified accessability for new devs, clean design) translation should be done in the presentation layer, for only the actual output needs translation
- cleaner separation possible between model, view and controller components of a module
- as the strings that need translation are known when the plugin is invoked, some more intelligent caching becomes possible, only strings that are displayed get translated
- allows to replace text with other mediatypes(e.g. pictures->first fallback icons(where appropriate), second english text, third placeholder like _TRx or I18n_x)
- for new modules: translation for the most common concepts comes right out of the box, but is overridable.
now as internationalization is in cvs, the neccessary changes would involve mostly a regexp job + minimal coding(excluding caching)
just my 2 €Cents
I am sorry that I did not respond to this post earlier, but I discovered Exponent too late.
My view of the current i18n system
1. The most usual way of i18n is a usage of variables or constants (currently used also in Exponent), but IMHO it is not very wise way. It is often difficult to understand the meaning of a phrase from the name of the variable and if you want to read the exact wording, you must open another file and find it there.
2. There are many repeated occurrences of the same phrase in different files. That causes repeated translation of the same phrase many times.
3. Developers and translators must manually edit changes in more files and they have to be very careful to not lose some of the phrases and to not change it’s variable name.
Another way of i18n
The best i18n system I have seen works this way:
1. the translation phrases (all texts) are written in PHP directly in the original wording, without variable aliases:
echo translate(’This is an original phrase.’);
The translate() function then provide translation to the current language.
2. There is a parser tool for translators which searches the whole project and when it find a new phrase, it appends it at the end of the language file. When it find an unused or deleted phrase, it sign it. IT causes that no untranslated phrase is lost, obsolete phrases are automatically deleted from translation files and there is no need to translate one phrase more than once.
3. The lang files seems like this:
;This is an original phrase 1. This is a translated phrase 1.
;This is an original phrase 2. This is a translated phrase 2.
Easy to understand and use for non-techie translators.
You can learn it at this project: http://plume-cms.net/
But IMHO the best way is to use gettext in the future.
which does pretty much the same thing as you described before :)
btw. one subtype of my original suggestion would have been(must be somewhere in these forums) a smarty plugin modifier where you write
which would have done exactly what you have asked for. had most of the groundwork already written, too. but fred's system was there at a time when mine wasn't, actually mostly because there was nobody i could discuss my ideas with. Still there is one now and i am stuck up to the ears with the core rewrite, so i have no time to work on a better system - if you want to give it a shot, i will be sure to help out.
problem with gettext is that it might not be bundled with the php version that is installed on the server
p.s. i, too, don't really(actually you could switch the previous two words) like the current i18n system, but now we have one that kinda works
You are right, it kinda works now and there are many other tasks with higher priority, so I think we can stay in i18n v2.0 as it is and we can replace it with i18n v3.0 in the far future, or when it will become urgent. For me it is sufficient to have a possibility to translate all the Exponent into my native language without hacking the core code. I prefer clean accessible tableless CSS-based output more than a perfect i18n system. But I will later explore the system I described in this thread. It seems that it works independently on gettext.
great, let me know, i'll be sure to lend a hand.
there is a "Maxim's Defiance corner" on the i18n whiteboards(at exponentcms.org), let us develop a proposal there.
i also registered you as a dev(at exponentcms.org) which means you've got write access to the dev board there.
> problem with gettext is that it might not be bundled with the php version that is installed on the server
There is a PHP-gettext project: PHP-gettext is developed to be able to read gettext MO files directly, without requiring anything other than PHP.
My current view is stop trying to reinvent the wheel and use the standard and time-tested solution.
Log in to post a comment.