Platonides wrote:
Krinkle wrote:
-- Other features
Variable replacement ($1, $2, etc.)
Fallback languages:
Getting language names
Escaping (ie. options = array( escape => html )
How much duplication will TsIntuition have with MediaWiki i18n code?
The basic principle is the same: Loading messages from i18n php files, translating at TranslateWiki, getting messages with fallback, etc..
However the main difference will be it's more basic / simplified. * No registered users * No dependencies on other code or database connections to be made. * Other than replacing variables and gender/plural there will be no parsing (ie. no ''markup'', {{templates}}, [[links]], {{#or}}, <whatever>) * No 'site language' vs. user language. * Language/gender choice come from cookies and/or browser agent. Rather then database user account preferences retrieval. * Isolated text domains. * No converters, backwards compatibility or wiki-environment factors to take into account.
One could describe TsIntuition as a lightweight i18n system for Toolserver tools written in a way that is compatible with TranslateWiki's workflow and as such is similar to other TW projects (like MediaWiki core/ extensions/Wikia).
Or one could describe TsIntuition as a stripped down version of MediaWiki's Language-class and rewritten without dependancies and with Toolserver tools in mind.
Both descriptions would match what TsIntuition is most of these functions are very simple in nature anyway. To save time and to avoid wheel- reinvention I have taken a closer look at MediaWiki's i18n system and may end up using some of it's code, why not ?
- Automated updates: Since the messages are file-stored in the
messages-directory of the tool. There's no need to keep track or update anything for you.
(...)
-- TranslateWiki
I'm currently in talks with TranslateWiki how to best set up the syncing system. Although initial chat with Nikerabbit didn't bring up any expected problem (as it's fairly similar other projects they translate), it still needs to be set up. I expect to have something going within one or two weeks.
Wouldn't DBA be preferible?
I'm not sure which definition of DBA you're referring to in this context. Can you elaborate ?
Thanks for your email, -- Krinkle