In den Docs steht zum Thema Zsatzfelder steht: "CustomFields sollten grundsätzlich in der Standardsprache des Shops bearbeitet werden (im Admin auf Standardsprache wechseln). So ist sichergestellt, dass die Vererbung der Werte für alle Sprachen gilt. "
Wenn ich in der Standardsprache einen Wert in einem aus SW5 migriertem Attritbut-Feld habe, das in der Standardsprache (de-DE) einen Wert hat, wird der mit {{ product.customFields['migration_AQ-SW5_product_attr4'] }} für die Fronatendsprache „Deutsch“ ausgegeben, aber nicht für Englisch, wo das Feld bei der Migration nicht befüllt wurde.
Sollte das funktionieren?
Gäne es ein Workaround für ein Feld im Template die Sprache Deutsch zu wählen (etwa {{ product.customFields['migration_AQ-SW5_product_attr4']|lang="de-DE" }})?
Evtl. löst das das Problem temporär, aber allein bei dem Namen des Feldes (migration_AQ-SW5_product_attr4) wird mir ja schon schlecht. Und dann schaut jemand in 24 Monaten auf den Shop und bekommt die Krise !
Ich würde hier nochmal eine Routine schreiben die dann die Namen säubert und dabei dann auch die Übersetzungen analysiert. Also fehlende Übersetzungen einfügt und vor allem, das Ganze in einem Log dokumentiert.
Kostet jetzt vielleicht 2 Tagen und spart am Ende 2 Monate !
Tut mir Leid, wenn Du die Krise bekommst und danke für deinen Vorschlag.
Allerdings löst es das Problem nicht, dass sich die Custom Fields anders verhalten, als in der Dokumentation dargestellt. Denn es ist auch bei neu angelegten Zusatzfeldern mit aussagekräftigem Namen so, dass sie, wenn in der Standardsprache befüllt, der Inhalt nicht in die anderen Sprachen übernommen wird.
Falls wer die Custom Fields per SQL in eine andere Sprache kopieren will (hier de nach en):
Die language_id entsprechend der ids in der language-Tabelle ändern.
UPDATE product_translation en
INNER JOIN product_translation de ON en.product_id = de.product_id
SET en.custom_fields = de.custom_fields
WHERE de.language_id=0x2fbb5fe2e29a4d70aa5854ce7ce3e20b AND en.language_id=0x018c20874e21739683f7b84f51a3c753