Sprachen werden beim Export durcheinandergewürfelt

[clausbde]

Sprog ist super, allerdings bin ich jetzt über folgendes in Version 1.5.1 gestolpert:

Beim Export würfelt er die Sprachen durcheinander, Beispiel:

In der rex_sprog_wildcard-Tabelle steht (letzte Spalte die Sprachen, nur zur Erklärung der dritten Spalte):
233 | 30 | 1 | z_cm_dienste_consent_manager_cookiename | Datenschutz Cookie | de
234 | 30 | 2 | z_cm_dienste_consent_manager_cookiename | Privacy cookie | en
235 | 30 | 3 | z_cm_dienste_consent_manager_cookiename | Cookie de confidentialité | fr
236 | 30 | 4 | z_cm_dienste_consent_manager_cookiename | Datenschutz Cookie | es
237 | 30 | 5 | z_cm_dienste_consent_manager_cookiename | Datenschutz Cookie | cn
238 | 30 | 6 | z_cm_dienste_consent_manager_cookiename | Datenschutz Cookie | pt
239 | 30 | 7 | z_cm_dienste_consent_manager_cookiename | Datenschutz Cookie | ru
240 | 30 | 8 | z_cm_dienste_consent_manager_cookiename | Cookie per la privacy | it
.
. [hier sind andere wildcards]
.
451 | 30 | 9 | z_cm_dienste_consent_manager_cookiename | Plik cookie ochrony danych | pl

Output CSV:
wildcard | de | en | fr | es | cn | pt | ru | it | pl
z_cm_dienste_consent_manager_cookiename | Plik cookie ochrony danych | Datenschutz Cookie | Privacy cookie | Cookie de confidentialité | Datenschutz Cookie | Datenschutz Cookie | Datenschutz Cookie | Datenschutz Cookie | Cookie per la privacy

pl wird zu de, en zu fr, fr zu pl etc

Ich schaue mir das gleich mal genauer an, das ist aber etwas merkwürdig.

[clausbde]

Meines Erachtens ist ein erster Workaround, wenn man in Zeile 26 in artefact.export.php das ORDER BY ergänzt:
$items = $sql->getArray('SELECT id, clang_id, wildcard, replace FROM '.rex::getTable('sprog_wildcard').' ORDER BY wildcard');
wird zu
$items = $sql->getArray('SELECT id, clang_id, wildcard, replace FROM '.rex::getTable('sprog_wildcard').' ORDER BY wildcard,clang_id');

(Sorry, Formatierung hakt wegen der Backticks, diese bitte mitdenken).

Aber: ich hatte zwischendurch das Phänomen, dass nach einem Import in einer Sprache 67 Elemente waren, in einer anderen nur 44 - das konnte ich aber nicht erneut nachvollziehen, dürfte aber bei nicht vorhandenen clang_ids den Export wieder zerhauen.

Vorschlag: beim Export die vorhandenen clang_ids des Systems durchlaufen.

Edit: letzte Zeile sprachlich optimiert :)

[clausbde]

Korrekturvorschlag für nicht vollständig synchronisierte Sprachen beim Export (vgl. issue #90):
Zeilen 48ff in artefact.export.php folgendes ersetzen

        foreach ($clangs as $clang_id => $replace) {
            $record[] = $replace;
        }

durch

        foreach (array_keys($clang_ids) as $clang_id) {
        $record[] = $clangs[$clang_id];
        }

[alxndr-w]

Die Sprachen werden da nicht durcheinander gewürfelt - es ist nach Schlüssel gruppiert.

Eigentlich ist das doch nur 1 Minute, die Datei in Excel aufzumachen und zu filtern. In welchem Use Case brauchst du das so häufig, dass sich da eine Optimierung lohnt?

[clausbde]

Die Redaxo-Tabelle ist in Ordnung. Wenn ich die aber über den sprog-eigenen Exporter exportiere steht ja in der ersten Zeile die jeweilige Sprache.
Und dabei kommt es im weiteren Verlauf bei in einer Sprache nicht angelegten wildcards dazu, dass sich innerhalb die Zeile die Felder verschieben, so dass diese in der falschen Sprachspalte stehen.
M.E. ist das zusammen mit den beiden anderen issues ein größeres Problem.
Sprich: wiederholtes Im- und Exportieren führt zu totalem Chaos, wenn man nicht alle Sprachen belegt.

[clausbde]

Kurz nochmal zur Verdeutlichung:
wenn ich de, en und fr als Sprachen angelegt habe und zwei wildcards in de und französich importiere und dann exportiere (über den sprog-Export) sieht es ungeführ so aus:

wildcard;de;fr
beispiel1;Beispiel 1 (de);Beispiel 1 (fr)
beispiel2;Beispiel 2 (de);Beispiel 2 (fr)

Füge ich jetzt in sprog eine wildcard hinzu, dann wird automatisch die Übersetzung für alle Sprachen eingefügt, der Export ist dann:

wildcard;de;en;fr
beispiel1;Beispiel 1 (de);Beispiel 1 (fr)
beispiel2;Beispiel 2 (de);Beispiel 2 (fr)
beispiel3;Beispiel 3 (de);Beispiel 3 (en);Beispiel 3 (fr)

D.h. in der Spalte en stehen die beiden ersten französischen Übersetzungen.

Noch chaotischer wird es dann, wenn man issue #91 betrachtet.

[tbaddade]

@clausbde Wenn ich dich richtig verstanden habe, importierst du neue Platzhalter, aber nicht für alle angelegten Sprachen sondern nur für eine gewissen Anzahl (de, fr). D.h. der Datensatz für den Platzhalter der nicht importierten Sprachen (en) fehlt in der DB?

Beim Anlegen eines neuen Platzhalters über das Backend, wird der Datensatz für alle anderen Sprachen mit angelegt.

[clausbde]

@tbaddade Richtig, ich importiere neue Platzhalter (und Übersetzungen) für einen Teil der Sprachen. Das Problem ist dann auch der Export (nach einem nicht sprachvollständigen Import), weil sich durch den nicht vorhandenen Platzhalter in der Sprache die anderen Felder in der Zeile sich dann jeweils nach links verschieben (und dann in der falschen Sprachspalte landen).

So ganz habe ich das jetzt nicht mehr richtig präsent, weil mein Workaround funktioniert. Aber das Beispiel vom 1.4.23 verdeutlicht das evtl.

Wenn man nur im Backend arbeitet und dort nur Import / Export nutzt ist das unproblematisch, schwierig ist es bei diesem Projekt über mehrere Webseiten, weil wir bereits fertige Sprachtabellen nutzen.

[tbaddade]

@clausbde Vielleicht könntest du für dein obiges Problem den aktuellen GH Stand einmal testen. Wenn #90 dann auch funktioniert, sollte sich #91 m.E. erübrigen.

[tbaddade]

ping @clausbde