[TYPO3-translators] EM and translations download

Robert Lemke robert at typo3.org
Fri Mar 3 10:58:59 CET 2006


Hi Kasper, Karsten and the list.

Kasper, I didn't read this paticular mail, so it was a misunderstanding 
yesterday when I said I did. Anyway ...

On Monday, 27. February 2006 18:48, Karsten Dambekalns wrote:

 > Aside from the EM, there needs to be support in the repository. The
 > easiest way would be (for official translations) to have another directory
 > there with another XML file (like extensions.xml.gz) and a MD5 file (like
 > extensions.md5). This way checks for updates would be easy and fast

Okay. Then we add a l10n subdirectory for each version:

  ter/
     t/
       e/
         templavoila-0.6.0.t3x
         templavoila-0.6.0.gif
         templavoila-0.6.0-l10/           
           de/
             locallang.xml
             pi1/
               locallang.xml
           dk/
             locallang.xml
             pi1/
               locallang.xml
         toaster-0.1.0.t3x
         toaster-0.1.0.gif
         toaster-0.1.0-l10n/
           xy/
             locallang_common.xml

What I don't like about it: We have too many small files. Karsten, do you see 
a chance to unpack .zip files in the EM without depending on the "unzip" 
binary? Then we could have:

  ter/
     t/
       e/
         templavoila-0.6.0.t3x
         templavoila-0.6.0.gif
         templavoila-0.6.0-l10/           
           templavoila-0.6.0-l10n-de.zip
           templavoila-0.6.0-l10n-dk.zip

All this would be included in the usual mirror sync and can therefore be 
downloaded from any mirror we'll have.

 > - CONTRIBUTION: People download an extension but it turns out that no  
 > translation is found on the translation repository for that  
 > extension. They install "llxmltranslate" and after making/adjusting  
 > their translation they use the EM to upload that file (I don't know  
 > how exactly). They have no contributed a translation.

Okay, I can add an upload function to the TER2 SOAP server (just like 
uploading extensions). That's easy to do, and it's easy integrating it into 
the EM.

Somewhen in the future we can have a FE plugin on some server which acts as 
the translator's framework I've been talking about. It will just use the same 
SOAP function for uploading translations we use from now on.

 > - NO BOTTLENECKS: Translations are finally independent of their  
 > extensions which is a good thing.

But who has the right to upload translations? Everyone? That means that 
someone could potentially override translated labels because he uploads an 
older version of his language pack.

This is why I propose a more capable framework. But as we can't have that 
right now, I suggest to only allow upload of language packs by registered 
translators and extension authors (for their extensions).

 > Ad "Contribution": It is unsure how the best way is. Definitely  
 > everyone should have a chance to contribute very easily but maybe the  
 > upload server is not the download server but rather a location from  
 > where contributions must pass through a basic check by people from  
 > the translator list? Also, what if people change one label and  
 > someone another label? So, basically we would at best like people to  
 > use CVS for contribution? This is still an open question but the  
 > technology is as simple as it gets with the new file structure in the  
 > language packs: There is simply no complex overhead! Just XML files.

Yes, again: The best solution I see is a frontend for translators with a 
minimal workflow and a set of usergroups. But we don't have to worry about 
that right now.

Finally: I think I can do my part before the final release of 4.0, it'll take 
about 2 hours. 

But I don't feel very well with introducing yet another feature without 
testing it really as we still have problems with other basic TER / EM 
functions. I mean, when do we really, really have a feature freeze for 4.0? 
At some point we have to stop introducing new features, because one thing is 
clear: a major release like 4.0 is ideal for *any* new great feature.

Cheers,
robert

-- 
Robert Lemke
TYPO3 Association - Research & Development
Member of the board
http://association.typo3.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-translators/attachments/20060303/82d541c0/attachment.pgp 


More information about the TYPO3-translators mailing list