[gune]

Hallo zusammen,

ich suche schon seit geraumer Zeit nach einer Erklärung, bzw. Lösung für folgendes Problem:

Wir haben diverse Artikel zunächst in Deutsch angelegt.
Nach Fertigstellung haben wir alle relevanten Artikel durch "Kopieren nach Englisch" auch für die englische Sprachversion angelegt.

Nun haben wir uns an die Übersetzung gemacht und dabei folgendes festgestellt:
Immer wenn wir einen "englischen" Artikel deaktivieren, weil der Text ja noch nicht fertiggestellt ist, wird auch der zugehörige "deutsche" Artikel deaktiviert.
Ist dieses Verhalten quasi das Standardverhalten oder stimmt etwas nicht mit unserer Installation?

Kann es sein, dass die Software davon ausgeht, dass ein Artikel immer für alle aktivierten Sprachen entweder aktiviert oder deaktiviert ist?

Wenn dem so ist, müsste man quasi erst alle englischen Texte fertigstellen und dann erst die englische Sprache an sich aktivieren.

Sorry für den Fall, falls dieses Problem doch schon irgendwo diskutiert wurde.
Leider habe ich hier bei oxid nirgends Hinweise gefunden, obwohl ich alles (FAQs, Wiki, Foren) durchsucht habe.

Viele Gruß,

Günter

[DanielS]

Originally Posted by gune

Hallo zusammen,

ich suche schon seit geraumer Zeit nach einer Erklärung, bzw. Lösung für folgendes Problem:

Wir haben diverse Artikel zunächst in Deutsch angelegt.
Nach Fertigstellung haben wir alle relevanten Artikel durch "Kopieren nach Englisch" auch für die englische Sprachversion angelegt.

Nun haben wir uns an die Übersetzung gemacht und dabei folgendes festgestellt:
Immer wenn wir einen "englischen" Artikel deaktivieren, weil der Text ja noch nicht fertiggestellt ist, wird auch der zugehörige "deutsche" Artikel deaktiviert.
Ist dieses Verhalten quasi das Standardverhalten oder stimmt etwas nicht mit unserer Installation?

Kann es sein, dass die Software davon ausgeht, dass ein Artikel immer für alle aktivierten Sprachen entweder aktiviert oder deaktiviert ist?

Wenn dem so ist, müsste man quasi erst alle englischen Texte fertigstellen und dann erst die englische Sprache an sich aktivieren.

Sorry für den Fall, falls dieses Problem doch schon irgendwo diskutiert wurde.
Leider habe ich hier bei oxid nirgends Hinweise gefunden, obwohl ich alles (FAQs, Wiki, Foren) durchsucht habe.

Viele Gruß,

Günter

Hast Du schon mal versucht, das Feld "oxactive" in der Tabelle "oxarticles" auch mutilangfähig anzulegen ("oxactive_1", "oxactive_2" etc.)? Einen Versuch ist's wert.

Vergiß nicht, nach der DB-Änderung den Cache zu leeren.

[gune]

Originally Posted by DanielS

Hast Du schon mal versucht, das Feld "oxactive" in der Tabelle "oxarticles" auch mutilangfähig anzulegen ("oxactive_1", "oxactive_2" etc.)? Einen Versuch ist's wert.

Vergiß nicht, nach der DB-Änderung den Cache zu leeren.

Hallo, erstmal Danke für den Tipp.
Falls ich das alles richtig verstanden habe, muss ich dazu auch den Feldtyp von "OXACTIVE" in der Tabelle "OXARTICLES" von zuvor "tinyint (1)" umstellen, z. B. auf "varchar (255)".
Ist das richtig?
Den Standardwert habe ich dabei gleich auf "oxactive_1" eingestellt.

Cache habe gelöscht.
Trotzdem ändert sich an dem Verhalten nichts.
Wenn ich dann im Backend einen Artikel editiere und auf "Aktiv" oder "Inaktiv" setze, hat das nach wie vor folgende Auswirkungen:

- Auch in der zweiten derzeit installierten Sprache Englisch wird der Artikel entsprechend aktiviert oder deaktiviert.
- Ausserdem wird der Wert wieder als "1" oder als "0" in die Tabelle eingetragen, was logisch klingt, weil ich die entsprechende Routine noch nicht geändert habe, dass der Wert auf "oxactive_1" usw. eingestellt wird.

Habe ich einen Fehler bzgl. DB-Anpassung gemacht?

Merci und viele Grüße,

Günter
[/LIST]

[DanielS]

Originally Posted by gune

Hallo, erstmal Danke für den Tipp.
Falls ich das alles richtig verstanden habe, muss ich dazu auch den Feldtyp von "OXACTIVE" in der Tabelle "OXARTICLES" von zuvor "tinyint (1)" umstellen, z. B. auf "varchar (255)".
Ist das richtig?
Den Standardwert habe ich dabei gleich auf "oxactive_1" eingestellt.

Cache habe gelöscht.
Trotzdem ändert sich an dem Verhalten nichts.
Wenn ich dann im Backend einen Artikel editiere und auf "Aktiv" oder "Inaktiv" setze, hat das nach wie vor folgende Auswirkungen:

- Auch in der zweiten derzeit installierten Sprache Englisch wird der Artikel entsprechend aktiviert oder deaktiviert.
- Ausserdem wird der Wert wieder als "1" oder als "0" in die Tabelle eingetragen, was logisch klingt, weil ich die entsprechende Routine noch nicht geändert habe, dass der Wert auf "oxactive_1" usw. eingestellt wird.

Habe ich einen Fehler bzgl. DB-Anpassung gemacht?

Merci und viele Grüße,

Günter
[/LIST]

Hallo Günter,

da hast Du mich leider falsch verstanden.

Das Feld "oxactive" bleibt, wie es war (tinyint(1) etc.). Zusätzlich legst Du Dir weitere Felder daneben an "oxactive_1", "oxactive_2" (je nach Sprachanzahl) ..., die die selben Einstellungen wie "oxactive" haben. Nach einem erneuten Leeren des TMP kannst Du's ja mal damit versuchen. Ob es tatsächlich funktioniert, kann ich Dir auf Anhieb aber leider nicht sagen.

[FrankMüller]

Ich grabe diesen Thread mal aus, da sich mir vor kurzem genau dieses Problem in den Weg gestellt hatte. Zufällig habe ich genau diesen Ansatz gewählt und das Feld dadurch Multilingual nutzbar gemacht. Hier aber zu meiner eigentlichen Frage: "Ist diese Lösung nicht etwas unsauber? Zumindest ist es nicht Update sicher, da man ja eigentlich einen eigenen Präfix vor eigenen DB-Feldern verwenden sollte. Was meint Ihr?"
Gruß Frank

[Marco Steinhaeuser]

Moin,

interessant, ich wusste gar nicht, dass das so funktioniert. Updatesicher ist es schon, es sei denn, die oxactive_x-Felder werden irgendwann mal im Standard ausgeliefert.

Gruß

[teutu]

Gibt es für die selektive Aktivierung von Artikeln mittlerweile ein Modul?