[TYPO3-core] XLIFF patches

[Dominique Feyer]

Xavier Perseguers wrote:
>> * Recycler is broken in the last patch set (I think it worked in some
>> earlier version). JS error: Uncaught TypeError: Object [object Object]
>> has no method 'replace' (probable the known [object] problem?).
> 
> I have the feeling both are related...

This is related, by patch solve the problem for em + recycler. This
patch will be pushed to gerrit later this evening.

> 
>> * The changes for Extbase have to be pushed separately (this means that
>> also from https://review.typo3.org/2573 the xlf file has to be removed
>> and pushed to Extbase review separately. This has to be done by
>> Dominique himself, and he has to sign the CLA (as I assume the CLA
>> prohibit to push code from other people).
> 
> I had understood that one could push it but I may have missed something,
> otherwise writing patches for Extbase/Fluid without having the CLA
> signed would not make sense and the work from the community in general
> would be lost. For sure one has to have sign the CLA to push to Gerrit
> but I'm sure the one who wrote the patch not (what is possible is that
> in such cases the author cannot be mentioned though).

I have not enought time to push the extbase patch. And no problem for me
if any body else can push it. Yes it's my code ... but the patch for
extbase is really small, and XLIFF is not really code.

> 
>> * I'm still not sure, at which places backwards compatibility is broken.
>> Extbase modules (workspaces) crash (without the required change for
>> extbase:
>> https://review.typo3.org/#patch,unified,2572,1,typo3/sysext/extbase/Classes/Utility/Localization.php).
>>
>> But how does this impact other extensions dealing with
>> $GLOBALS['LOCAL_LANG']?
> 
> I'd say that we know we want to go in that direction. The work on XLIFF
> is not finished yet, if some (not all of course :D) non-Core extensions
> are broken because of edge-cases play with the API or simply because
> some parts are not yet ready (support for deprecated LLPHP files for
> instance), that's not that bad from my POV, we have a developer snapshot
> tomorrow (alpha2) and we will fix them until alpha3.

Yes extension dealing with $GLOBALS['LOCAL_LANG'] directly (without
using the official API) will now receive an array (before it was
directyl a string). But we can't do anything to solve that, i think ?

Dominique