Die Zukunft für Entwickler, composer, transifex, ...., was muss/kann und lohnt sich?
Ok, soviel habe ich schon mitbekommen, ohne composer läuft in naher Zukunft nichts mehr, wird Zeit sich damit zu beschäftigen.
Jetzt frag ich mich gerade, wie läuft das zukünftig mit den Übersetzungen? Da gibt es ja im Prinzip zwei Möglichkeiten.
a) über Pullrequests in GitHub
b) über transifex
Für mich als Hobby Entwickler wäre Variante a) sicherlich die einfachere. Aber sind "meine" Übersetzer, die bisher ein Webformular hatten, wirklich dazu in der Lage?
Variante b) wiederum ist für Übersetzer einfacher, es bleibt beim Webformular, ein wenig Einarbeitung und ein Account sind nötig. Aber hier hat man als Entwickler wieder mehr Aufwand.
(die ich noch nicht im Detail kenne)
Anders gesagt, mache ich es den Übersetzern einfacher oder mir selbst. Hmm....
Wie macht Ihr das in Zukunft und warum?
Transifex Profis, Hilfe nötig!
Hi,
ich habe ein bisschen damit gespielt und versuche meine jetzigen Sprachfiles zu pushen.
Jedoch versteht transifex wohl nur eindimensionale arrays:
PHP-Code:
$LANG['bla'] = 'blubb';
jedoch nicht:
PHP-Code:
$LANG['modul']['bla'] = 'blubb';
(type = PHP_ALT_ARRAY )
Und nu? Sicherlich muss ich da über ein anderes Format gehen, wie xliff oder sowas. Aber wie komme ich nun wieder dahin? (und dann wieder zurück....)
ctb - Error 400 Bad Request Meldung
OK, mit der contao-toolbox (ctb) konnte ich meine PHP Sprachfiles in xlilff umwandeln lassen, aber ich bekomme die nicht damit zu transifex hochgeladen, kommt ein Error 400 Bad Request Meldung. (beim Versuch die Ressource anzulegen)
Mit dem tx Client jedoch bekomme ich die hochgeladen.
Genauso der umgekehrte Weg, mit tx runterladen und mit ctb zurück wandeln in PHP Arrays, so funktioniert es.
Das runterladen mit ctb werde ich heute Abend mal probieren ob das geht.
ist das ne korrekte en xliff Datei?
Irgendwie fehlten da die target Zeilen, obwohl die ja auch keinen Sinn manchen da die identisch wären:
Code:
<?xml version="1.0" ?><xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file datatype="php" date="2013-05-12T22:05:44+02:00" original="default" source-language="en" target-language="en">
<body>
<trans-unit id="MSC.tl_spielwiese.id">
<source>ID</source>
</trans-unit>
<trans-unit id="MSC.tl_spielwiese.picture">
<source>Picture</source>
</trans-unit>
<trans-unit id="MSC.tl_spielwiese.name">
<source>Name</source>
</trans-unit>
</body>
</file>
</xliff>
composer Profis, sagt mal was....
Hi,
wie sollte denn meine Datei Struktur auf GitHub aussehen, um später ohne große Änderungen meine Erweiterungen mit einer composer.json auszustatten und alles funktioniert?
Ich habe mehrere "Arten" (src/ , system/, ...) gefunden auf Github (habe mir einige Contao Erweitertrungen angesehen).
Testen müsste man das ganze dann auch können, und ich meine jetzt nicht per Kommandozeile sondern aus dem BE von Contao. (composer-installer, ...)
Falls die Composer Pakete (https://github.com/ContaoCommunityAlliance/...) schon nutzbar sind, wäre ne kurze Info wie schon hilfreich.
Oder jemand macht gleich ein c2g Paket dafür. :D
Erweiterung nun dank composer-dist Installation nicht mehr voll funktionsständig
So,
dank Andreas Isaak sind nun zwei meiner Erweiterungen (dlstats, botdetection) mit einer composer.json bestückt und auch von mir in packagist registriert.
"dlstats" jedoch funktioniert im BE bei der Detail Ansicht nicht mehr. :mad:
Grund scheint zu sein, dass die Module ja nicht direkt in system/modules/ installiert werden, sondern in meinem Fall unter /composer/vendor/bugbuster/, wodurch eine Zeile wie:
PHP-Code:
require('../../../initialize.php');
nun nicht mehr passt.
Das ist blöd, hier muss ich also nun abhängig vom Installer bzw. von Ort der Installation das require anpassen.
Bin gespannt was da noch alles kommt.
Edit: so, angepasst, die Erweiterung geht nun in beiden Arten der Installation.
