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

[Ernesto Baschny [cron IT]]

Xavier Perseguers schrieb am 25.08.2011 18:35:

>>> 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)

I would find it very charming, if all extensions would be translateable
via this service, else the Extension Manager will only find the
translations for the core? Or how would the user be able to update their
extension translations? Only by updating the extensions, and hoping that
the author has included the "most recent translations"?

But I see that the problem is not only technical, but also of resources,
to get it done and to get a robust server infrastructure in place. Maybe
we could / should consider that individual developers *could* use their
own Pootle server and just export their translations to "somewhere"? So
that we don't overstress the "Core Pootle", but still enable developers
to provide their XLIFF+XML translations to TER?

>> 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.

Agreed.

>> 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 there is a extdeveval function to transform .xlf files into a
"monster-locallang.xml", I see no maintainance problem, as it happens
automatically.

>> 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

But an "usual" old-school extension has its localization files scattered
over their sources. So how does this ease the management? E.g.
tt_news... Find the .xlf files: :)

ChangeLog
class.ext_update.php
cm1
compat
csh
de.locallang.xlf
de.locallang_tca.xlf
doc
ext_conf_template.txt
ext_emconf.php
ext_icon.gif
ext_localconf.php
ext_tables.php
ext_tables.sql
flexform_ds.xml
flexform_ds_no_sPID.xml
fr.locallang.xlf
fr.locallang_tca.xlf
js
lib
locallang.xml
locallang_tca.xml
mod1
modfunc1
pi
res
tca.php
todo.txt

But I agree that with Extbase extensions (Resources/Private/Language) or
more "organized" modern extensions, it should make no difference. I
still prefer the suffix. :)

Cheers,
Ernesto