Actions

XliffTeamMeeting 2011-06-23

This meeting take place just before the TUG meeting in Lausanne. During this meeting we discuss different aspect of the current implementation, and what need to be done before 4.6 feature freeze.

Present

  • Dominique Feyer (XLIFF project leader)
  • Xavier Perseguers (4.6 release manager)
  • François Sutter
  • Laurent Cherpit

Improve caching

Has the caching framework will be the default caching system for 4.6 we need to use it. So we need to change the current implementation. The current proposed change is on Gerrit: https://review.typo3.org/2930

We are breaking ExtJS

Actually no standard API are used by ExtJS bases extension. Many extension use the TYPO3.lang array to manage the conversion of key to translated string. Some extension use directly t3lib_div::readLLFile to populate the array. Has the return value is not any more a array of string, but an array of array (tu support XLIFF plural forms), this modification break many (all ???) ExtJS extension.

We have a RFC for a new official l10n API for ExtJS based extension: Request for Comments:: ExtJS l10n API. This API have been discuss with the Phoenix team who currently agree with it.

We have done many patch for core ExtJS based extension (workspace, linkvalidator, em, ...) but we can not provide a patch to all the TER extension. So we need to found a solution to allow the use of TYPO3.lang.key (who actually return an array object, but we need a solution to return the translated string for the singular form). It's actually quiet hard to use the "magic getter" in a cross browser way (without using a bunch of VBScript to support Internet Explorer 6,7,8).

This point doesn't have a solution right now. Laurent Cherpit has done some test, but without a viable solution currently.

Normalization of the current l10n implementation

Actually the lang key are not ISO based (Canadian French, must be fr_CA). We are currently checking what need to be changed to normalized the implementation (core, translation server, extension manager, ...). With the use of the fr_CA key, it's more easy to setup fallback language to fr, before en

Help developer during the migration to XLIFF

We need to add a feature to extdeveval to convert LLXML to XLIFF automatically.

Pootle Server (the new translation server)

The new translation server is up and running but not in production actually. We plan to switch from the current translation server to the pootle server just after the alpha3 release. Alpha3 will be released with all the core XLIFF file. Many thing need to be done before that (building language pack containing XLIFF + LLXML in the same zip archive, for backward compatibility).

Actually we plan no change on the TER, the language pack will keep compatibility with older TYPO3 version, by providing LLXML file). The synchronization workflow between the translation server, and the TER mirror doesn't need any modification.

The new l10n API (PHP)

If we have time, we try to provide an new implement to use the plural forms provided by XLIFF. But it's not the priority for the 4.6. The priority is to have stable parser and all the current l10n method compatible with XLIFF (without plural support). So this API can come later.

Updated by Dominique Feyer almost 11 years ago · 4 revisions