[TYPO3-german] Nachtraegliches aendern der Defaultsprache

Stephan Schuler Stephan.Schuler at netlogix.de
Wed Mar 9 19:18:23 CET 2011


Hallo Pascal.



Ich halte das für nicht praktikabel. Wenn du dir meinen Aufsatz sparen möchtest hier die Kurzfassung: Lass es bleiben.

Der Wert "-1" im Zusammenhang mit Sprachen meint "alle". Ein Datensatz mit sys_language_uid=0 wird nur in Standardsprache ausgeliefert, ein Datensatz mit sys_language_uid=-1 in allen Sprachen (sofern keine Übersetzung existiert).
Wenn du jetzt bisherige Standardsprachdatensätze von 0 auf -1 setzt, werden die in allen Sprachen angezeigt. Soweit kann das vielleicht noch erträglich sein, hilft dir aber auch nicht weiter. Langfristig möchtest du aber sicherlich die bisherige Standardsprache auf einen neuen, sinnvollen Wert setzen. Außerdem wirst du dir mit der -1 eben selbst in die Quere kommen, sofern du einzelne Inhaltselemente mit "alle Sprachen" im System hast.



Mir fallen spontan drei Arten der Übersetzung ein, die alle gesondert behandelt werden wollen.



1.: Übersetzbare Tabellen:

Es gibt Datensatzarten, bei denen Standardsprache und Übersetzung in einer Tabelle existieren. Der beliebteste Vertreter dürfte tt_content sein. Der Grund dafür ist einfach: Es gibt Inhalte, für die nur eine Sprachvariante vorliegt aber keine Standardsprachvariante.
Bei sprachlichen Inhalten muss man unterscheiden: Übersetzungen und losgelöste nicht-standardsprachliche Texte.
Übersetzungen haben ein Mutterelement, zu dem sie die Übersetzung sind. Losgelöste nicht-standardsprachliche Texte haben das nicht. Eine Übersetzung ist immer eine Übersetzung eines Standardsprachelements oder eines "alle Sprachen"-Elements. Übersetzungen von Übersetzungen existieren nicht.

Ausgangssituation:
tt_content:100 hat sys_language_uid:0 (Standardsprache, Deutsch)
tt_content:101 hat sys_language_uid:1 und l18n_parent:100 (Englisch)
tt_content:102 hat sys_language_uid:2 und l18n_parent:100 (Spanisch)
tt_content:103 hat sys_language_uid:1 und l18n_parent:0 (Englisch, keine Übersetzung)

Was du tun musst:
tt_content:101 auf sys_language_uid:0 ändern und l18n_parent auf 0. Standardsprache hat kein Übersetzungs-Mutterelement. Ein SQL-Query dafür ist einfach.
tt_content:100 auf sys_language_uid:3 ändern und l18n_parent auf tt_content:101. Hier scheiterst du, weil sich die rückbezügliche Abhängigkeit nicht in einen einfachen SQL-Query schreiben lässt.
tt_content:102 auf l18n_parent:101 ändern. Auch das wirst du nicht ohne erweiterte Logik hinbekommen.
tt_content:103 auf sys_language_uid:3 ändern
Ich gehe davon aus, dass ein Standard-Sortierproblem (a:b nach b:a durch drei Updates (mit a=c, b=a, c=d) nicht die Hürde ist.

Ein eher unschönes aber für den laufenden Betrieb nicht notwendiges Problem: l18n_diffsource (die Änderungsinhalte der Übersetzung gegenüber den Standardsprachwerten um erkennen zu können, ob sich zu einer Übersetzung gehörende Standardsprachwert seit dem letzten Speichern der Übersetzung geändert hat und ggf. eine Korrektur der Übersetzung notwendig ist ... wenn ich mich nicht Irre). Dass im Backend alle deutschen Übersetzungen zunächst rot angezeigt werden darf der Redakteur ignorieren.



2.: Gesonderte Übersetzungstabellen:

Es gibt weiterhin Datensätze, bei denen die Standardsprache und die Übersetzung in unterschiedlichen Tabellen existieren. Vertreter hiervon ist zum Beispiel pages. In der Tabelle pages liegen *immer* die Standardsprachwerte, Übersetzungen in pages_language_overlay. Das anhand von tt_content erklärte Problem ist hier ein wenig erweitert, weil die Übersetzungstabelle nicht zwangsläufig alle Felder der Ursprungstabelle enthalten muss sondern nur diejenigen die auch übersetzt werden können.



3.: Flex-XML:

Die dritte Variante sind solche Datensätze, bei denen die Übersetzung einzelner Felder als übersetzbares XML (Flexform) vorliegt. Zugegeben, das ist die seltenste. Ein Beispiel aus dem TYPO3-Core fällt mir hier zunächst nicht ein. Hierbei muss das XML innerhalb des Datensatzes bearbeitet werden. Dass so etwas nicht mit SQL geht sondern erweiterte Logik notwendig ist dürfte klar sein.



3+x:

Und damit die Sache nicht zu einfach wird: Die dritte Variante lässt sich natürlich kombinieren mit der ersten bzw. der zweiten. Wenn man "normale Plugins" erzeugt, hat man im TYPO3-Backend einen "Plugin"-Tab in dem pluginspezifische Konfigurationen hinterlegt werden können. Dabei handelt es sich um das in der dritten Variante angesprochene XML. Es ist nun Sache des Extensionautors, ob das Plugin ein nicht-übersetztes XML beinhaltet (und somit durch Übersetzen des Plugin-tt_content überstezt werden muss) oder ob es ein sprachabhängiges XML enthält. In diesem Fall sollte das Plugin als "alle Sprachen" hinterlegt werden und die Übersetzung dazu innerhalb des einen Plugin-Inhaltselements im "Plugin"-Tab.
In diesem Fall muss man leider aus der tt_content-Tabelle (die nach meiner obigen Aufzählung eigentlich die einfachste Behandlung bekommen könnte) einzelne Zeilen herausfiltern und als "Variante 3" behandeln.



Ich möchte deshalb dringend davon abraten, im Nachhinein an der Sprachkonfiguration der Datensätze in der Datenbank zu schrauben. Das kann eigentlich nur schief gehen.



Was genau hast du denn vor? Geht es darum dass deine Redakteure teilweise kein Deutsch können und deshalb lieber englische Texte eingeben wollen? Dann kann ich dir leider auch nicht helfen.

Oder willst du im Frontend URLs, die den Sprachparameter bislang für englische Inhalte enthalten und für deutsche Inhalte weglassen, in Zukunft aber für deutsche Inhalte einen Sprachparameter enthalten und für englische nicht?
Dann könntest du via Typoscript den URL-Paramter index.php?L=0 auf config.sys_language_uid=1 und index.php?L=1 auf config.sys_language_uid=0 biegen. Das ist zwar auch keine tolle Lösung und ggf. fliegen dir dabei einige Extensions um die Ohren (indexed_search hat den L=0-Parameter irgendwo hart codiert, das könnte für andere Extensions auch noch zutreffen), dürfte aber leichter zu korrigieren sein.



Grüße,



Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Website: media.netlogix.de


--
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Internet: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt



-----Ursprüngliche Nachricht-----
Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von Lehnhoff, Pascal
Gesendet: Mittwoch, 9. März 2011 15:28
An: TYPO3-german at lists.typo3.org
Betreff: [TYPO3-german] Nachtraegliches aendern der Defaultsprache

Hallo,

wir haben eine fertige Typo3 4.4 Installation, mit Template und Inhalten.

Folgende Sprachen sind angelegt:

ID 0: Deutsch
ID 1: Englisch
ID 2: Spanisch
ID 3: ....

Nun wollen wir die Sprachen "tauschen", Englisch soll default werden mit ID 0 und Deutsch soll ID 1 bekommen.

Auf der Cebit, am Typo3 Stand, hieß es, es gäbe die Moeglichkeit Sprache 0 auf -1 zu setzten, um Sprache 0 neu vergeben zu koennen.
Wie das genau funktionieren soll ist uns allerding nicht klar.

Hat jemand eine Loesung für das nachtraegliche ändern der Defaultsprache?


_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


More information about the TYPO3-german mailing list