Hi, ich war kurz irritiert, dass meine Übersetzungen nicht über die Translation API ankommen. Jetzt bin ich das mal bei Github durchgegangen und bemerke, dass ‘locale’ zu ‘shop’ wurde - in der ganzen Klasse: https://github.com/shopware/shopware/commit/8403aea50cab8217f6d3c8cbe018ee498bc6e0d7 Es gibt den Hinweis “Create / update / delete with localeId are still supported as legacy.” - das ist definitiv nicht der Fall. Mit nur der Übergabe der localeId im data array wird die Übersetzung NICHT durchgeführt. Wenn eine gültige shopId im gleichen Zug statt der localeId gesetzt wird funktioniert das. Ein Hinweis, dass sich die API dort geändert hat wäre hilfreich gewesen. Kann das noch wer anderes bestätigen? … Schöne Grüße, Niklas
Hi, wie sieht den der genaue HTTP-Aufruf bei dir aus? Oder verwendest du die API über PHP? Der Fallback ist nämlich nur im HttpController hinterlegt: https://github.com/shopware/shopware/bl … ns.php#L45 Heiner
Hallo Heiner! Danke für die Nachricht, ich benutze die Resourcen lokal - also nicht über die REST API. Stimmt, den Fallback sehe ich - der fehlt leider lokal. Bedeutet - wenn ich bei den Übergaben lokal die localeId statt ‘localeId’ als ‘shopId’ bezeichne klappt das? Die localeId ist aber doch eine andere ID als die shop id, so ganz schlüssig finde ich das gerade nicht 
Ich möchte Übersetzungen ja für eine Sprache setzen, nicht speziell für einen Shop. Wenn ich den Fall hätte das es mehrere Subshops mit der gleichen Sprache existieren möchte ich ja nicht die Übersetzungen für jeden Shop, sondern einmalig nur für die Sprache machen … Schöne Grüße, Niklas
Hi, ja schon, aber auch unter Shopware 4 war die „localeId“ eigentlich die „shopId“. Mit Shopware 5 wurde es nur (richtig) benannt. Das Verhalten hat sich also nicht geändert. Heiner
Wir haben innerhalb von SW4 die localeId bei der Übertragung verwendet haben (aus s_core_locales!). Das ist auch exakt (!) so in der SW4 Doku enthalten: http://wiki.shopware.com/REST-API-%C3%9Cbersetzungs-Endpunkt_detail_1693.html#Translation_3 [quote] localeId integer (Fremdschlüssel Locale - s_core_locales Benötigt[/quote] Jetzt ist die Rede von shopId - ja, die Klasse der Translation Resource wurde unbenannt, aber die ganzen Objekte wurden von locale auf shop geändert. Deswegen sieht das so aus, als ob nicht mehr mit der ID aus s_core_locales gearbeitet wird, sondern mit der id aus s_core_shops, korrekt? Wenn das so wäre hätte das mit Sicherheit nicht nur für uns größere Auswirkungen, da definitiv nicht meistens localeId == shopId ist. Das wäre doch eine völlig andere Weise Übersetzungen zu setzen. Würde bedeuten, jetzt würde man Übersetzungen pro Shop (!) setzen, und nicht mehr pro Sprache/Locale (!) Da bräuchte ich eine Rückmeldung, weil - das würde bei uns tiefgreifende Änderungen mit sich bringen die leider nicht ansatzweise so in der neuen Doku abzuschätzen waren … da steckt ja offensichtlich deutlich mehr hinter als nur eine string ID zu ändern. Ich würde mich sehr über Feedback freuen. Schöne Grüße, Niklas
Hi Niklas, nein, das ist kein Problem. Im Frontend war es schon immer die shopID und nicht die localeID. Das hat sich auch bei vielen Kunden als praktischer erwiesen, da man dann z.B. auch verschiedene SEO-Texte für verschiedene Shops anbieten kann. Damit man aber die Übersetzung nicht doppelt pflegen muss, gibt es in den Shop-Einstellungen die Möglichkeit ein Fallback-Shop zu hinterlegen. Edit: Vielen Dank noch für den Hinweis auf den Wiki-Artikel. Den werden wir noch entsprechend aktualisieren. Heiner
Dann hätte das im Upgrade-Guide wirklich anders thematisiert werden müssen. Das ist ja nicht nur bei uns eine Änderung von Übersetzung pro Sprache zu Übersetzung pro Shop, jeder Entwickler der die Translation API nutzt wird das umbauen müssen. Halte ich dann eigentlich für etwas gefährlich im API Controller einfach localeId in shopId zu setzen, ich schätze mal, dass auch noch andere Anbieter da erst später drauf kommen. Weil Fakt ist - alle Entwickler die sich vorher an die Doku gehalten haben und die localeId gegeben haben schauen ab SW5 in die Röhre, so wie wir jetzt. Ja, dann muss ich in den sauren Apfel beißen und das umbauen 
Schöne Grüße, Niklas
Hi, ja, verstehe. Aber das Problem ist ja, dass die API in Shopware 4 in diesem Punkt falsch war und es dann später zu komischen Ergebnissen im Frontend kam. Jetzt hat das Feld den richtigen Namen und man kommt auch schneller auf die Lösung, statt sich über die vermeintliche „localeId“ zu wundern. Heiner
Das heißt, Übersetzungen über die Resource bis SW5 sind eigentlich defekt und nicht produktiv nutzbar? Dann würde ich mir die Arbeit der Abwärtskompatibilität sparen und diese nur ab SW5 supporten. Danke für die schnelle Auskunft, Niklas
Die Dokumentation sollte bei euch auch immer noch angepasst werden … http://community.shopware.com/Using-the-Shopware-4-Rest-API_detail_1576.html#Getting_translations Die Beispiele … $translationResource-\>getList(0, 1, array( array('property' =\> 'translation.localeId', 'value' =\> 2), array('property' =\> 'translation.key', 'value' =\> 200), array('property' =\> 'translation.type', 'value' =\> 'article') )); oder $translationResource-\>getList(0, 10, array( array('property' =\> 'translation.localeId', 'value' =\> 2) )); … können nicht funktionieren, da ab SW5 die localeId nicht mehr existiert und stattdessen die shopId notwendig ist (die getList() funktioniert sonst definitiv nicht). Ich kann mich erinnern, dass Ihr das Mapping in der REST API drin habt (von locale zu shopId), die Nutzung der lokalen Ressourcen wie im Beispiel haben dieses aber nicht drin. Schöne Grüße, Niklas
Ja, die Doku für Shopware 5 findest du hier: https://developers.shopware.com/develop … /rest-api/ Und für Shopware 4 kannst du es ja mit einer IF-Bedinnung auch kompatibel machen. Beispiel: if (Shopware::VERSION == '\_\_\_VERSION\_\_\_'|| version\_compare(Shopware::VERSION, '5.0', '\>=')) { //Shopware 5 } else { //Shopware 4 } Gruß Heiner
[quote=“Heiner Lohaus”]Ja, die Doku für Shopware 5 findest du hier: https://developers.shopware.com/develop … /rest-api/[/quote] Okay, in eurer Doku sind oft nur an bestimmten Stellen Hinweise, dass diese z.B. in höheren Versionen nicht mehr so funktionieren … [quote=“Heiner Lohaus”] Und für Shopware 4 kannst du es ja mit einer IF-Bedinnung auch kompatibel machen …[/quote] Ja, das ist mir schon klar Danke für Tipps natürlich, aber ich habe bereits dutzende Stellen drin, die abhängig der Shop-Version anders laufen - nur ich habe ja vorher bereits ausführlich geschrieben, dass ja eine ganz andere Logik erforderlich ist wenn ich Übersetzungen statt einer Sprache explizit einem Shop zuweise. Also, inhaltlich, wie welche Daten für welchen Shop nun bereitgestellt werden. Zwischen ERP und Shop können ja durchaus andere Datenstrukturen bestehen, deswegen ist das manchmal eben nicht mit einem if erledigt Aber - wie gesagt - trotzdem Danke für die Antwort. Wir haben das jedenfalls schon länger angepasst und die Übersetzungen klappen. Schöne Grüße, Niklas