[TYPO3-core] RFC #29248: Cannot use own translation with XLIFF

[Xavier Perseguers]

Hi,

>> If an extension developer wants to create a multilingual extension with
>> XLIFF files, he has no other choice than using the official TYPO3
>> translation server to provide the corresponding translations. This is
>> not realistic as the translation server is not intended to be used for
>> each and every extension available on TER.
>
> Hm, why not? Wouldn't it scale to allow it? I would find it rather bad
> if it wouldn't, as it is usually not the extension developer that wants
> to deal with the "translation".

No, it wouldn't scale unless we switch to some monster server. But the 
question is left open and we should have a clear line of conduct to 
import further extension into it. (Who said A-class extensions? :D)

>> Solution:
>> Allow translations to be stored next to the main language:
>>
>> locallang.xlf
>> fr.locallang.xlf
>> de.locallang.xlf
>> locallang_db.xlf
>> fr.locallang_db.xlf
>>
>> Note:
>> This has the side-effect of enabling this support for ll-XML as well.
>
> Why is one coupled with the other? XLIFF support is not backported
> (yet?) to 4.5, so why would any change be required in 4.5? The

Nothing is *required* for 4.5, this was more thought as an idea. But I 
expected it to be rejected. I've the same opinion as Steffen G. in his 
answer. Don't backport just because it's cool :)

Regarding backport of XLIFF into 4.5, in the end, we don't plan to do it 
(we discussed that recently but I don't remember when). Current 
implementation of XLIFF support and the way the Pootle (translation) 
server was configured allows a transparent handling/generation of ll-XML 
files out of XLIFF ones. The localization API has not been enhanced - 
yet for 4.6 - (to support plurals or placeholders) and as such, it 
really does not make sense to backport it to 4.5, even if it's a LTS.

After all, LTS should be stable and as long as we don't introduce 
breaking changes in a newer versions that could easily be minimized with 
some backport to LTS, we should not let LTS grow. At least, that's my POV.

> ext-author wanting to support 4.5 *and* later will have to ship
> locallang.xml *and* XLIFF files anyway, so he can have multiple xlf
> files and a single monster locallang.xml file.

Exactly. This was just a way to let people split their monster 
locallang*.xml files because it's really a pain to maintain when an 
(own/private) extension grows over time and for multiple languages.

> If it has to be split up, I would rather don't use the language-code as
> prefix, but as a suffix:
>
> locallang.xlf
> locallang.fr.xlf
> locallang.de.xlf
> locallang_db.xlf
> locallang_db.fr.xlf

I prefer the prefix for 2 reasons:

1) It's is 1:1 compatible with what is sent by translation server (have 
a look into typo3conf/l10n
2) It eases management with files grouped by language

>> As such, this could be backported to 4.5 and 4.4 as well. This would
>> allow developers currently dealing with gigantic locallang*.xml files to
>> split them (e.g., take EXT:seminar).
>
> Would allow, but with no further benefit apart from the cosmetics?

As said, let developers and agencies have a better (possible) way of 
dealing with monster locallang*.xml files as long as they have not the 
privilege to use a 4.6 or above ;-)

> I guess I didn't get it right. Anyway, if a subset is intended to be
> backported with a different subject and description, why not create an
> own issue for it? The new one can reference the master-one.

Of course! I agree. But I guess it won't be done anyway.

>> Note 3:
>>
>> Kind regards
>
> Note 3.. Kind regards? :)

Something like that :)

Cheers

-- 
Xavier Perseguers
Release Manager TYPO3 4.6

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org