Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Status
Es sind keine weiteren Antworten möglich.

martinwolf

Offizieller Servicepartner
SPBanner
6. September 2012
3.385
263
Ich bin der Meinung, dass dieses Thema irgendwann schonmal angesprochen wurde, konnte über die Suche aber nichts dazu finden, deshalb ein neues Thema.

Es ist ja bekannt, dass JTL Shop 4 bei mehreren Sprachen mit einem Fallback auf die Standardsprache arbeitet. Das wiederum ist aber sehr von Nachteil. Beispiel:

Es gibt 2 Sprachen, DE und EN.

Artikle in WAWI EN
Titel: übersetzt auf EN
Kurzbeschreibung: gibt es keine, warum auch immer, sollte aber egal sein, wird ja dann nur nix angezeigt (so die Vermutung aus Betreibersicht)
Beschreibung: übersetzt auf EN

Artikel in WAWI DE
Titel: übersetzt auf DE
Kurzbeschreibung: übersetzt auf DE
Beschreibung: übersetzt auf DE

Im Shop hingegen wird nun bei EN Sprache auch der EN Titel, die EN Beschreibung ABER die DE Kurzbeschreibung ausgegeben. Dadurch landen dann auch falsche Übersetzungen in den Metaangaben. Aus Betreibersicht eigentlich absolut fatal. Für viele Muttersprachler ist das ein Grund den Shop nicht mehr zu besuchen. Ebenso dürfte Content der mehrere Sprachen unter einer URL aufführt für Google relativ unsinnig erscheinen. Welche Folgen das im Detail haben kann weiß wohl nur Google selbst, ein Rankingverlust wäre da aber durchaus zu erwarten.

Daher dürfte es meiner Meinung nach keinen Fallback im Frontend geben. Wenn ein Artikel in der WAWI angelegt ist, dann sollte einfach im Mindesten der Titel für alle aktivierten Sprachen eine Pflichtanagbe sein. Ansonsten kann dieser nicht an den Webshop abgeglichen werden. Wer nichtmal einen Produkttitel übersetzt hinterlegen will, braucht auch keine Mehrsprachigkeit. Allgemein wird das gesamte Thema Mehrsprachigkeit durch diesen Fallback auf die Standardsprache - hinfällig.
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Den Fallback kann man sicher via Plugin am Hook 110 (Funktion fuelleArtikel()) beseitigen. Also als Zwischenlösung bis bei JTL dazu eine Entscheidung getroffen wurde und diese auch umgesetzt wird.
 

jernst

Gut bekanntes Mitglied
3. Januar 2011
582
7
Berlin
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Ich ziertiere mal:
und im Weiteren:
als Zwischenlösung bis bei JTL dazu eine Entscheidung getroffen wurde und diese auch umgesetzt wird

Das kann doch nicht allen Ernstes der Stand eines "modernen mehrsprachigen Shopsystems" und ein aus den Hotfix Zyklen resultierender Workflow sein.
Hat sich denn überhaupt mal jemand angeschaut wie das im Ergebnis aussieht, überlegt was das in Zeiten von "Content is King" auch nur ansatzweise für den Shopbetreiber bedeutet und mal einen halben Gedanken daran verschwendet, wie solch ein - positiv formuliert - Durcheinander von Google indiziert wird?
In den Monaten in denen wir uns nun mit 4.xx befassen, weil wir uns dazu entschlossen haben, werden wir den Eindruck nicht los, daß der Shop 4 eine Art Einbahnstrasse ist.

Ich lasse einfach mal die ganzen ungefixten Fehler aussen vor, zu denen es eine "Bastelanleitung" für den geneigten Shopbetreiber gibt, aber keinen Hotfix o.Ä.
Ich lasse auch mal die ungezählten Plugins aussen vor, die heute noch nicht Shop 4 fähig sind oder als solche in sehr überschaubarer Anzahl angeboten werden und immer "blöderweise" gerade bei uns einen Fehler haben, den man ja mit Austausch der Codezeile ..... - siehe oben - fixen kann.
Ich möchte auch nicht über die "Fortschritte" im Bereich der Contentdarstellung, -bearbeitung oder -erstellung sprechen - schönes Beispiel von vielen der CKEditor im Auslieferzustand - und wie ein einziger Servicepartner, diese fundamentalen Defizite mit einem Plugin zumindest teilweise löst.

Ich möchte einfach nur mal darstellen, daß wir mittlerweile daran zweifeln daß es auf Seiten JTL und auf Seiten der sich für Shop 4 interessierenden Servicepartner, ein unverändert ernsthaftes Interesse an der Weiterentwicklung / gerne auch Fertigentwicklung von Shop 4 gibt.

Unsere Wahrnehmung ist die, daß der Schwerpunkt auf der WAWI und dem Connector liegt, vielleicht mit dem Ziel ein anderes Afterbuy zu werden, nicht aber sich an konkurierenden Shopsystemen vorbei zum führenden Shopsystem zu entwickeln. Wir waren auf der Conncet 2015 recht aufmerksame Zuhörer und Zuschauer, doch hatten wir den Nebensätzen von TL´s Keynote damals noch eine andere Bedeutung beigemessen. Ich erinnere mich noch sehr gut daran, daß er die Bedeutung der WAWI als Kernprodukt von JTL hervorhob und dies nicht nur in einer ex ante Betrachtung.

Vielleicht noch abschließend zu diesem Beitrag. Ich schreibe ihn nicht als Hobbyprogrammierer, der seine Freizeit verbringt indem er sich mit JTL beschäftigt. Ich schreibe diesen Beitrag als Unternehmer, der in der Verantwortung für unsere Mitarbeiter steht. Und ich schreibe ihn, weil wir mit diesem Shop Geld verdienen müssen.

Aus diesen Gründen würde ich mich freuen, wenn auch diese paar Zeilen mal zum Anlaß genommen werden, sich über eine grundsätzliche Frage einen Überblick zu verschaffen, warum sollten Unternehmer Shop 4.02 einsetzen. Ich meine nicht WAWI und ich meine nicht Connector, ich meine Shop 4.02
Und schon jetzt für die, die dann wieder ankommen und Kritisierende für "unwürdig" halten, wenn wir gehen wollen, dann schreibe ich keinen Artikel, dann bin ich wie der eine oder andere einfach weg und jemand anders bekommt pünktlich unser Geld.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
6.719
1.616
Berlin
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Darum habe ich meinem petticoatshop Kunden, das Update vorerst verboten.
 

jernst

Gut bekanntes Mitglied
3. Januar 2011
582
7
Berlin
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

:) Vielleicht richtig, nur mit 3.20 "gegen" Amazon, Zalando und die anderen "Verdächtigen" ..... na ich weiß nicht ob das im Fashion Bereich so der richtige Weg sein kann. Programmiertechnisch vielleicht, aber marketingmäßig .....
Aber ich kann festhalten, wir sind da nicht so ganz alleine mit unserer Sicht.
Ich habe nichts gegen die 4er Version, die Ideen sind m.E. zielführend, aber derzeit halt derzeit nur die Ideen und das ist das was ich bemängel.
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Wer mit Amazon, Zalando und Co. konkurrieren möchte muss aber auch selbst Hand anlegen und nicht immer drauf warten bis alles out of the box funktioniert... (Natürlich sollte es obb funktionieren)... JTL arbeitet aber auch mit Hochdruck an der 4.03 in der viele wenn nicht sogar alle gemeldeten Bugs behoben sind, mehr kann man aktuell auch nicht erwarten...


Gesendet von iPad mit Tapatalk
 

jernst

Gut bekanntes Mitglied
3. Januar 2011
582
7
Berlin
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Was glaubst Du denn wer für die fundamentalen Veränderungen im Onlinegeschäft verantwortlich ist, die ungezählten JTL Shops auf der 4.02er Basis? Da habe ich so meine leisen Zweifel .....

Aber mal ohne Zynismus, daß wir unser System bis zu einem gewissen Grad selbst anpassen müssen ist uns bekannt und in den vielen Jahren, die wir mit JTL arbeiten gängige Praxis. Doch wenn man als Hersteller ein Produkt anbietet und Fehler findet, dann sollte man sich damit zielführend befassen. Und zielführend heiß für uns im operativen Geschäft absehbar. Das sich JTL intensiv um die Behebung kümmert ziehe ich seit Monaten nicht in Zweifel, aber halt seit Monaten .......

Mir geht es mit diesem Beitrag vorrangig nicht darum rum zu nörgeln, warum der für 4.03 nicht kommunizierte Festigstellungstermin nicht eingehalten wird.
Ich stelle mir halt folgende Frage: Wenn 4.02 out of the box ein modernes, zeitgemäßes Shopsystem darstellen soll, grundsätzliche Fehler nicht gefixt, sondern nur mit grossen Updates behoben werden, Basics im Bereich der Contenterstellung / -bearbeitung einfach von Hause aus nicht vorhanden sind - und das nicht erst seit 4.xx -, ich also nur in der Zusammenarbeit mit Servicepartnern das System unter dem Aspekt einer gewissen Relevanz in Bezug auf Mitwettbewerber zum Laufen bekomme, ich aber bei den Servicepartnern eine gewisse Frustration, gepaart mit fehlender JTL - bezogener Motivation spüre und teilweise klar kommuniziert bekomme und ..... ich könnte da noch vieles weiter schreiben ......, ist dies das System was ich gerne meinem Mitwettbewerber empfehle oder ist das das System, was mich in meiner Onlinestrategie beflügelt und unterstützt?

Allein der Fehler, den Martin Wolf oben beschrieben hat, ist doch verherrend oder kennst Du da eine Rufnummer bei Google, wo ich jemandem erklären kann, ja das mit der Mehrsprachigkeit meinen wir zwar ernst, aber die Software hakt noch und wir haben da sowieso ein ganz anderes Verständnis von Mehrsprachigkeit, als der Algorythmus und der Hersteller arbeitet ja an der Fehlerbehebung und sowieso müßte Google ja für die Fehler Verständnis haben?
Nein, kennst Du nicht? Wir leider auch nicht ...... Und was machen wir da? Quellcode handgeklöppelt verändern, gerne auch mit Servicepartnern und weiter auf 4.03 warten.

Wie ist das also mit der Zukunftsfähigkeit? Warum sollte ich mich heute noch einmal für den JTL Shop entscheiden? Wie kommt es, daß wir für die WAWI regelmäßig alle paar Wochen eine Fix erhalten, wir aber seit Monaten auf die Behebung "einiger" Fehler in der 4.02 warten? Und warum verstehen hier so viele "Shopbetreiber" das Wirkprinzip nicht, wenn ich im Shop keine Umsätze mache, benötige ich auch keine WAWI?
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

ich also nur in der Zusammenarbeit mit Servicepartnern das System unter dem Aspekt einer gewissen Relevanz in Bezug auf Mitwettbewerber zum Laufen bekomme, ich aber bei den Servicepartnern eine gewisse Frustration, gepaart mit fehlender JTL - bezogener Motivation spüre und teilweise klar kommuniziert bekomme und ..... ich könnte da noch vieles weiter schreiben ......

Also dazu möchte ich einfach Mal in den Raum werfen > "Vielleicht hast du ja den falschen Servicepartner?!"

Versteh das nicht falsch. Ich betreue hier einen der größeren JTL-Kunden mit mehreren Millionen Jahresumsatz und jenseits 100.000 Paketen pro Jahr. Wir haben hier zwei Shops im Einsatz + eBay und Amazon und alles über JTL. Im letzten Jahr haben wir notgedrungen die Wawi-Beta Phase miterlebt, da wir auf einige Features nicht mehr warten konnten.
In dieser Beta-Phase gab es zwar Bugs aber JTL war stets zu Stelle (wenn auch manchmal mit geringer Wartezeit wenn es nicht wirklich ein Bug war, der den Betrieb lahm gelegt hat) um den Fehler zu beseitigen.

Darauf folgte die JTL-Shop4 Beta mit welcher ich die Entwicklung des neuen Viverni Shops begonnen hatte, und auch dort trotz massiver Modifikationen am Shop, war und ist JTL immer hilfsbereit wenn es Mal Bugs und/oder Fragen gibt. Manchmal dauert es natürlich ein paar Tage bis ich eine Rückmeldung erhalte, dass finde ich aber auch mehr als fair, da mMn wir Servicepartner zwar geringfügig bessere Reaktionszeiten seitens JTL haben sollten (im Vergleich zum JTL-Endnutzer), um eben auch unseren Kunden in angemessener Zeit antworten zu können.
Auch heute noch in Zeiten der 4.02 > 4.03 erhalten wir SP auf Anfrage den aktuellen Build des Shop 4.03 (der natürlich eventuell auch noch Bugs haben kann und nicht für den produktiven Einsatz bestimmt ist), dies erlaubt uns aber auch in ~15min mit einem Tool wie Beyond Compare die Unterschiede zur 4.02 zu erkennen und eben dadurch z.B. schnell die notwendigen Code-Zeilen zu finden mit denen sich ein Problem bei einem Kunden schon vorab erledigen lässt.
Manche Bugs sind natürlich zu umfangreich dafür aber für viele kleine Bugs klappt das wunderbar. JTL freut sich im Gegenzug darüber, dass wir (ich nehme an auch andere SPs machen dies) in unserer Entwicklungsumgebung bereits die 4.03 "Beta" laufen haben und denen so aus unserem mehrsprachigen System mit inidividuellem Template und knapp 20.000 Artikeln weiteres Feedback geben können, damit eben bis zur fertigen 4.03 eventuell noch weitere Kleinigkeiten schnell miterledigt werden können, oder Usability-Verbesserung gemacht werden.

Das Ganze harmoniert sehr gut, es ist allerdings keine "Bring-Schuld" von JTL jedem SP alles anzubieten, sondern eine "Hol-Schuld" vom SP. Wenn ich etwas möchte, dann frag ich einfach, manchmal gibt es dann als Antwort auch ein "Nein" und muss eben selbst überlegen (z.B. wenn ich Mal "zu faul" bin um mir komplexe MSSQL Queries zu "basteln" und ich dann jemanden bei JTL danach frage).

Neben JTL (die hier im Forum auf Grund der vielen Arbeit aktuell nicht sonderlich aktiv sind - aber vl. auch weil einige Servicepartner hier gute Arbeit leisten und ohnehin zu vielen Fragen die Antworten parat haben) gibt es dann noch einen eigenen Servicepartnerchat in dem auch dein Servicepartner herzlich willkommen ist. In diesem wunderbaren Chat helfen wir SP uns gegenseitig, da jeder nun Mal seine Stärken und Schwächen hat (JavaScript, PHP, MySQL, MSSQL, Apache Webserver, nginx Webserver, Smarty3 Template Engine, JTL-Pluginsystem, usw...).

Fakt ist: Der JTL-Shop 4 in Version 4.02 hat einige Bugs die für "große User" relevant sind und behoben werden müssen. An deren Behebung wird auch gearbeitet und der Großteil sollte mit 4.03 erledigt sein. Die kleinen die auch kein Budget für die Arbeitsstunden eines SP haben und viel am Shop selber machen, haben vermutlich auch nicht die Ressourcen einen rechtskonformen mehrsprachigen Shop zu betreiben und sollte daher von dem Bug auch nicht betroffen sein.
Der JTL-Shop4 bietet eine solide Basis hat aber an vielen Ecken mehr Potential. Ob hier teilweise Dinge nicht umgesetzt werden um uns SP noch Raum für Plugins zu lassen, da die Features ohnehin nur für einen Teil der User relevant wären oder ob Sie einfach nur nicht gemacht werden, weil es eben nur für einen Teil der User relevant wäre kann ich dabei aber nicht sagen.
Wer aber bei den Großen mitspielen will muss auch ordentlich "investieren"... wer dann Angst hat, dass die Updatekosten dann immens in die Höhe steigen, da durch mehr Anpassungen ja auch der Aufwand für den SP beim Update steigt, dem kann ich als Beispiel hier nur unseren Shop nennen, hier ist das Template bis auf eine Hand voll Formularen und Unterseiten nicht Mal mehr Ansatzweise identisch mit dem Evo Template und neben diversen Plugins sind auch einige Core Dateien individuell angepasst und selbst in dem Umfang schaffe ich es ein Update von 4.02 auf 4.03 "Beta" an einem Nachmittag zu erledigen.

Ich schweife hier ein wenig aber, aber wenn ich schon dabei möcht ich das auch Mal hier los werden. Meiner Meinung nach gibt es hier zu viele kleine Nutzer die gleich groß mitspielen wollen obwohl das Budget dafür noch nicht vorhanden ist (gleich mehrsprachig, gleich alle Marktplätze, gleich alles individuell...) und dann eben enttäuscht sind, weil der Shop nicht alles gleich perfekt macht und man ja noch ein Plugin kaufen müsste oder eine Arbeitsstunde an nen SP bezahlen müsste um eine Änderung zu integrieren.
Dazu kommen noch jene, die ihre eigene Arbeitszeit nicht schätzen und lieber 4 Tage im Forum nachfragen und selbst basteln für Dinge die ein fähiger SP in 30 Minuten erledigen könnte.
Ich bin ehrlich gesagt der Meinung, dass sich jeder JTL Nutzer einen oder zwei Servicepartner seines Vertrauens suchen sollte (zwei dann wenn einer z.B. nur für Wawi und WMS "Profi" ist bzw. nur das machen möchte und der zweite eben den Shop wie seine Westentasche kennt, und einer wenn du einen hast der in allen Bereichen solides Grundwissen hat, und die Kontakte mit anderen SPs um eben für Detailfragen auch schnell die Lösungen zu bekommen) und mit diesem gemeinsam Stück für Stück seinen Online-Shop auf das eigene Geschäft anzupassen. Natürlich kostet das eine Stange Geld, aber die Zeiten in denen man einfach Mal eben einen xt:Commerce Shop startet und morgen 200 Bestellungen hat sind vorbei. Ich habe oft das Gefühl, dass viele hier den Start in die Selbständigkeit überstürzen und sich vorab nicht informieren welche Kosten entstehen für Server / Einrichtung / Shop / Template / Wareneinkauf / Anpassungen / usw... und dann aber auch nicht in der Lage sind zu sagen > ok, so wird das nichts. Besser Gewerbe abmelden > paar Jahre sparen und dann richtig, bzw. eventuell Geldgeber suchen!?
Und zu guter letzte haben wir noch die jenigen die im Forum Dinge Fragen für die wir SP Stunden oder Tage investiert haben uns das Know-How anzueignen und dann "beleidigt" sind wenn wir die fertige Lösung nicht kostenlos im Forum bereitstellen.

Jene Shopbetreiber die hier auf "mehreren Hochzeiten" Tanzen und X Servicepartner beauftragen weil der eine dies für 2€ weniger macht und der andere eben dort günstiger ist, sparen an der falschen Stelle. Siehe Click-Licht.de, die haben einen SP gefunden und machen (soweit ich informiert bin) alles mit diesem Servicepartner, damit ist sichergestellt, dass dein SP dein System und seine Eigenheiten in- und auswendig kennt und alles "rund" läuft.

Anyway, sorry für's abschweifen.

Fazit: Als SP mit sehr engem Kundenkontakt zu einem mittelgroßen "Voll-JTL" Kunden finde ich natürlich die Informationspolitik von JTL könnte besser sein (aber auch daran wird bei JTL - wie im Forum von David auch schon angesprochen - intern gearbeitet, nur dauert es bei 70 Mitarbeitern solch neue "Prozesse" einzuführen) allerdings geht es bei der Softwareentwicklung an allen Ecken ordentlich voran.
 

jernst

Gut bekanntes Mitglied
3. Januar 2011
582
7
Berlin
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Ich verstehe Dich schon richtig und stimme Dir in Deinen Ausführungen voll zu.

Doch wenn ich all das was Du schreibst zusammenziehe, ist das Ergebnis Deiner guten Arbeit ein Shop, der - ich überzeichne bewußt - irgendwas mit JTL zu tun hat. Und in diese Richtung geht es wohl bei uns auch. Ergo bleibt die Frage, ab wann ist die Arbeit von JTL am Shop so rudimentär, daß darauf getrost verzichtet werden kann, da ja die guten Servicepartner getrieben von ihren Kunden letzendlich die Impulse initiieren und die Umsetzung realisieren? Ich erinnere mal in diesem Zusammenhang an die Entwicklung bei XT-Commerce, auch wenn das ja auch ein Open Source Problem war.

Und da bin ich wieder bei der Kernfrage, die ich u.a. aus den Fix - Zyklen WAWI versus Shop 4.xx ableiten kann, welchen Stellenwert wird der Shop für JTL zukünftig haben.
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.174
1.078
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Allein der Fehler, den Martin Wolf oben beschrieben hat, ist doch verherrend


Sprachlich gibt es leider viele verherrende Fehler/Missstände, man kann nichtmal die Kategorien in einer Box anzeigen lassen (sidepanel) wenn man den opcache nutzt/nutzen will.


Wie kommt es, daß wir für die WAWI regelmäßig alle paar Wochen eine Fix erhalten, wir aber seit Monaten auf die Behebung "einiger" Fehler in der 4.02 warten? Und warum verstehen hier so viele "Shopbetreiber" das Wirkprinzip nicht, wenn ich im Shop keine Umsätze mache, benötige ich auch keine WAWI?


Hier kommt halt leider ein wichtiger Aspekt zu tragen. Die WaWi ist eben nicht nur JTL Shop, sondern auch ConnectorWaWi. Ich kenn jetzt die Updatezyklen der Connectoren (noch) nicht, aber du hast mit deinen Ausführungen, aus meiner pers. Sicht, leider zu 99.9% recht.




Also dazu möchte ich einfach Mal in den Raum werfen...




Eigentlich ein sehr schöner Post und eine schöne "Zusammenfassung", jedoch nicht wirklich aus Kundensicht geschildert.


Fakt ist: Der JTL-Shop 4 in Version 4.02 hat einige Bugs die für "große User" relevant sind und behoben werden müssen.
Der Editor, Sprachprobleme, PayPal Plugin, Cronjob/Blindgrafikproblem, opcache problem....das sind keine Bugs für "grosse User". Ich weiss zwar was du damit sagen willst, bin jedoch diesbezüglich absolut nicht deiner Meinung (was ja ok ist :) ).
Jürgen hat es auch richtig zusammengefasst, dass diese ganze Hotfixbastelei einfach nervig ist und viel Zeit kostet (egal ob selbst oder einem SP).
Schon allein die Argumenation hier von JTL ist einfach kaufmännisch falsch/ungeschickt/kurzsichtig.
Neuer Interessent X ladet sich 4.02 runter und kann nichtmal seine CMS Seiten richtig optisch gestalten und müsste dann ein Ticket schicken (kann er nicht bei CE) oder sich im Forum zurechtfinden um hier einen Bugfix zu finden = unnötiger Zeitaufwand, wenn man anständige Versionen macht (4.021.... etc). Aber ja, ist nicht der Stil von JTL -> kostet jedoch "sicher" XX unnötige Tickets und den Verlust von möglichen neuen Kunden. Sorry, abgeschweift, eh nicht mein Bier.


Ob hier teilweise Dinge nicht umgesetzt werden um uns SP noch Raum für Plugins zu lassen...
Ich wette mit dir, das ist so. Auch wenn es aus Kundensicht etwas ärgerlich ist, ist es jedoch eine Bindungsstrategie von JTL für seine SP (damit eben Kunden DL einkaufen müssen), die nachvollziehbar ist.
Unprofessionell sind jedoch Dinge, die seit Jahren auf der todo stehen, "versprochen" wurden und nach X Jahren (aufgrund von Prioritätsverschiebungen, Desinteresse oder was auch immer) noch immer in irgendeiner verstaubten Pipeline liegen sich für SP jedoch nicht auszahlen (wie man ja sehen kann, da nicht realisiert von einem SP) und JTL einfach auch nicht macht.


schaffe ich es ein Update von 4.02 auf 4.03 "Beta" an einem Nachmittag zu erledigen.


Das ein Update von einem SP einen Nachmittag dauert, finde ich absolut vertretbar und in Ordnung. Hier müsstest du jedoch auch noch, fairerweise, die Testzeiten dazuschreiben/anführen.
Denn das Update alleine ist es ja nicht und gerade bei recht viel Individualität, muss alles einzeln und sorgfältig von dir auch testet werden. DAS ist der timekiller und nicht das überspielen von Updatedatein oder Vergleichen von Inhalten.
Ich habe hier verstärkt das Gefühl, dass viele Kunden (und/oder SP/JTL) viele Dinge einfach nicht wirklich anständig testen (ich meine jetzt nicht dich damit, eine rein generelle Erfahrung anhand der Vielzahl an Bugs).


Dazu kommen noch jene, die ihre eigene Arbeitszeit nicht schätzen
Oja, damit hast du vollkommen recht. Bei 4.02 wollten wir auch was für die Allgemeinheit machen und Fehler/Hilfestellungen hier publizieren, damit nicht jeder so dumm (mit SP!) suchen muss und XX Stunden verschei**t, wenn eh wir es schon machen müssen.
Bei 4.03 interessiert uns dann das alles nicht mehr, jede Kleinigkeit wird per Ticket geschickt, sofern es einer unserer beiden SP nicht lösen kann.


dass dein SP dein System und seine Eigenheiten in- und auswendig kennt und alles "rund" läuft
Theoretisch die beste Möglichkeit. Man muss nur darauf aufpassen, dass dieser SP nicht zu gross wird, denn dann dauert jede Kleinigkeit erst wieder ein paar Wochen (was bei Erweiterungen nicht tragisch ist, bei Bugbehebung jedoch schon).


Zum Fallback -> ich Nervensäge bin ziemlich sicher bei jedem Sprachbug vorhanden gewesen..möchte mich echt dafür entschuldigen, dass wir nicht nur DE einsetzen.
Der ganze derzeitige Stand des Fallbacks ist einfach in manchen Punkten total schwachsinnig.
G Export Plugin -> vollkommen wertlos mit/bei Sprachen von Produkten, die nicht übersetzt sind (ja, soll vorkommen und kann schon seinen Sinn machen -> Markttesten zb.)
Hier wäre ein Plugin/Einstellung in der Admin sinnvoll um jeden selbst Dinge in die Hand zu geben (wie mit nicht vorhandener Übersetzung bei CMS, Artikelbeschreibung, Titel, Kurzbeschreibung etc. umgegangen werden soll), aber he, wer soll das machen? JTL ? Haha, dafür gibts zuwenig INteressenten. SP? Haha, dafür gibts zuwenig Interessenten. Was bleibt? Lediglich das "haha"...

Oh, war wieder alles nicht konstruktiv genug...steht auf meiner todoliste und mir ist bewusst, dass ich die Kommunikation verbessern muss, aber keine Sorge, dass gehe ich an.
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig



Mach Mal ein Ticket auf, oder frag im SP-Chat. Und schon solltest auch du bei Bedarf den aktuellen Build der 4.03 bekommen. JTL gibt den natürlich nur raus wenn sich zeigt, dass du den Build zum Testen nutzt und auch Feedback gibst und nicht damit du irgendwie schon vorab Updates machen kannst.




Eigentlich ein sehr schöner Post und eine schöne "Zusammenfassung", jedoch nicht wirklich aus Kundensicht geschildert.
Ich sehe das gemischt. Sowhohl aus Kundensicht, da wir SP nicht überall "Vorteile genießen, als auch aus SP Sicht gerade in Bezug auf folgende Aussagen, da ich hier eher vermute, dass der SP sich nicht die Mühe macht im SP-Chat oder direkt bei JTL bei Bedarf nachzufragen:
...ich aber bei den Servicepartnern eine gewisse Frustration, gepaart mit fehlender JTL - bezogener Motivation spüre und teilweise klar kommuniziert bekomme und .....






Bezüglich der Updates und Tests > auch bei mir geht das recht zackig, ich teste dann Bestellablauf mit diversen Zahlungsarten, Warenkorb, Navigation und eben jene Dinge in denen ich in meiner Git-Repo sehe, dass sich dort der Code "maßgeblich" geändert hat.


Bezüglich "JTL macht Dinge vl. nicht damit SP Plugins verkaufen können" > meine Erfahrung als SP, ich hatte Mal einen Slider als Plugin der sich gut verkauft hat, da es aber ein allgemeins Feature war, dass viele gebraucht haben, war ein gleichwertiger Slider oder teilweise sogar umfangreicher im nächsten Shop3 Update enthalten. Ich hatte auch Mal ein AJAX Suche Plugin entwickelt, JTL hat einige Zeigt später "JTL-Search" vorgestellt, da es eben für viele interessant ist.


Bezüglich SP wird zu gross > Hast du schon versucht deinem SP einfach Mal ne minimale (1% oder bisschen weniger) Umsatzbeteiligung an deinem Shop anzubieten, eventuell in Kombi mit einer monatlichen Pauschalgebühr sofern der Shop (noch) nicht soviel abwirft. Plötzlich wird dein SP aktiv mit neuen Ideen für den Shop auf dich zukommen und gerne 200 Stunden dran arbeiten ohne dir Unsummen in Rechnung zu stellen + egal wie gross er wird, du wärst auf jeden Fall immer das wichtigste Projekt auf seine Liste.


Bezüglich des "Fallbacks" > siehe oben - Shopbetreiber die gleich groß starten möchten aber keinen rechtskonformen mehrsprachigen Shop auf die Beine bekommen, alleine weil ja auch die "erheblichen Artikelmerkmale" ohnehin übersetzt werden müssen usw. damit dein Bestellablauf für einen Kunden der in Englisch bestellt rechtskonform ist. Wenn du oder andere nicht die Ressourcen habt um alles zu übersetzen könnt ihr euch über den Fallback aufregen, der aber nur zum Problem wird, weil eben bei euch die Inhalte nicht übersetzt wurden.


Bezüglich des " Cache Problems" > bei den Boxen verwenden wir eigene Funktionen, daher kann ich dazu nichts sagen. Das allgemeine Sprachproblem, dass Links und andere Dinge die Sprache nicht ändern usw. ist mit 4.03 aber behoben.
 

jernst

Gut bekanntes Mitglied
3. Januar 2011
582
7
Berlin
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Naja, da hätten wir ja auch Interesse dran und würden uns grundsätzlich mit reinhängen.
Aber ich würde da gerne mal ein Zitat verwenden:
JTL- Shop wird in deutscher und englischer Sprache geliefert und kann um jede von JTL-Wawi unterstützte Sprache erweitert werden. Produktdaten können bereits in verschiedenen Sprachen in JTL-Wawi hinterlegt und somit in allen angeschlossenen Webshops genutzt werden.
Quelle: https://www.jtl-software.de/JTL-Shop-Organisation-Verwaltung

Auch wenn man hier restriktiv interpretiert sagen könnte, genau so funktioniert es doch, so glaube ich doch hinter dieser Formulierung einen Sinn zu sehen. Insoweit meine ich, daß JTL hier in der Pflicht ist, zumal wir den Shop gemietet und gehostet haben, also jeden Monat einen hübschen Betrag abbuchen lassen. Übrigens in echtem Geld, kein Geld mit grundsätzlichen Fehlern und von einem gedeckten Konto. Konnte ich mir jetzt nicht verkneifen ;)
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Naja, das es nicht optimal ist stimmt ja. Ich sag ja nur, dass hier bei vielen im Geschäftsbetrieb ja nicht Mal die Voraussetzungen erfüllt sind um mehrsprachig zu verkaufen, die machend dann halb und schon fällt der Bug auf.


Gesendet von iPad mit Tapatalk
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.174
1.078
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

1.) Bezüglich der Updates und Tests > auch bei mir geht das recht zackig, ich teste dann Bestellablauf mit diversen Zahlungsarten, Warenkorb, Navigation und eben jene Dinge in denen ich in meiner Git-Repo sehe, dass sich dort der Code "maßgeblich" geändert hat.


2.) Bezüglich "JTL macht Dinge vl. nicht damit SP Plugins verkaufen können" > meine Erfahrung als SP, ich hatte Mal einen Slider als Plugin der sich gut verkauft hat, da es aber ein allgemeins Feature war, dass viele gebraucht haben, war ein gleichwertiger Slider oder teilweise sogar umfangreicher im nächsten Shop3 Update enthalten. Ich hatte auch Mal ein AJAX Suche Plugin entwickelt, JTL hat einige Zeigt später "JTL-Search" vorgestellt, da es eben für viele interessant ist.


3.) Bezüglich SP wird zu gross > Hast du schon versucht deinem SP einfach Mal ne minimale (1% oder bisschen weniger) Umsatzbeteiligung an deinem Shop anzubieten, eventuell in Kombi mit einer monatlichen Pauschalgebühr sofern der Shop (noch) nicht soviel abwirft. Plötzlich wird dein SP aktiv mit neuen Ideen für den Shop auf dich zukommen und gerne 200 Stunden dran arbeiten ohne dir Unsummen in Rechnung zu stellen + egal wie gross er wird, du wärst auf jeden Fall immer das wichtigste Projekt auf seine Liste.

4.) Bezüglich des "Fallbacks" > siehe oben - Shopbetreiber die gleich groß starten möchten aber keinen rechtskonformen mehrsprachigen Shop auf die Beine bekommen, alleine weil ja auch die "erheblichen Artikelmerkmale" ohnehin übersetzt werden müssen usw. damit dein Bestellablauf für einen Kunden der in Englisch bestellt rechtskonform ist. Wenn du oder andere nicht die Ressourcen habt um alles zu übersetzen könnt ihr euch über den Fallback aufregen, der aber nur zum Problem wird, weil eben bei euch die Inhalte nicht übersetzt wurden.


5.) Bezüglich des "Cache Problems" > bei den Boxen verwenden wir eigene Funktionen, daher kann ich dazu nichts sagen. Das allgemeine Sprachproblem, dass Links und andere Dinge die Sprache nicht ändern usw. ist mit 4.03 aber behoben.

Hab mir erlaubt, deine Punkte mit Zahlen zu versehen :)

1.) Git-Repo sehe....maßgeblich
Es muss keine maßgebliche Veränderung sein, dass Dinge verschoben sind, im Ablauf nicht mehr funktionieren oder ein Zusammenspiel von Plugin/Template/Core nicht mehr läuft, dass weisst du doch selbst ganz genau :)

2.) Ja, versteh ich. Wenn das Interesse gross ist und ein allgemeiner Part ist, sehe ich es ja auch ein, dass JTL hier das mit reinnimmt, aber schau dir das Search vom Basti an, das läuft auch gut, trotz JTL Search (weil es einfach einen anderen Weg geht, nehme ich mal an).

3.) Wir sind selbst Hersteller und seit knapp 10 Jahren am Markt, ich glaub dir, dass eine 1% Umsatzbeteiligung toll wäre :D
Wir sind kein frischer Shop der Dropshipping betreibt, haben 2 Anwälte in unterschiedlichen Bereichen plus Patentanwalt, betreiben Ama+ebay+unicorn also wir können uns schon einen SP leisten. Aber auch ein SP ist kein Zauberer und ich bin auch nicht ständig bereit, für Core-Bugs externe DL zu beauftragen. Klar muss man abwägen ob man lieber >6 Monate wartet oder es einfach machen lässt und für JTL Bugbehebung einfach externe damit beauftragt und diese selbst bezahlt.

4.) Es gibt aber auch Shopbetreiber die WACHSEN. Neue Märkte erschliessen, Märkte testen etc. Sprecht doch alle bitte nicht immer ständig von "gross starten möchten", es gibt auch noch immer Unternehmen mit gutem Wachstum die schon seit XX Jahren am Markt stehen und sich nicht an Grenzen rund um Berlin oder München aufhängen möchten. Die rechtskonformen Dinge kannst du dir problemlos zukaufen, dies zählt nicht (für mich) als Ausrede für die ganzen Bugs in diesem Bereich.
Du bist SP und weisst ziemlich sicher, welcher Aufwand es ist, eine neue Sprache hinzuzufügen und alle Übersetzungen dafür zu machen. Das ist nichts, wo man von einer Agentur mal nur ein paar übersetzte Produktbeschreibungen in die WaWi einträgt.
CMS, SEO Texte, FAQs, rechtliche Dinge, Variablen, interne Verweise, Boxen, Mails, Sprachverwaltung, Template....

5.) Es ist schön, dass es mit 4.03 mal hoffentlich behoben ist, aber 4.02 ist am 18.12.2015 erschienen, vor knapp 4 Monaten...beziehungsweise Shop 4.0 ist am 14.10.2015 erschienen, vor knapp 6 Monaten....

die machend dann halb und schon fällt der Bug auf.

Also ist der User daran schuld, dass ein Bug auffällt/vorhanden ist? Made my day.
Du hast im Grunde ja nicht vollkommen unrecht, benutzt jedoch eine eingeschränkte Sichtweise um Bugs zu verteidigen/rechtfertigen.

Finde auch die Argumentation ob gross/klein fehl am Platz. Wir sind sicher nicht klein, aber es muss vollkommen irrelevant sein, ob ein Händler gross oder klein ist.

Beim genannten Beispiel vom Martin (betrifft uns ja auch) ist es einfach eine falsche Sichtweise von JTL, wie mit dem Thema Fallback umgegangen wird. Wobei ich korrigiere mich jetzt mal selbst, sie ist vielleicht nicht falsch, sie ist eher nur nicht vollkommen durchdacht und erfordert - so finde ich - Nachbesserung.
Mir ist auch bewusst, dass das Thema Google für JTL eher unwichtig ist (siehe XXX BEiträge und Antworten von offizieller Seite hier) und dass auch hier kommt: dann übersetzt halt alles.
Es wäre jedoch besser, sich dieses Thema anzunehmen, die Problematik zu verstehen und Lösungen durchzusprechen/anzubieten (gerne im Dialog). Klar ist die für JTL einfachste Lösung: übersetzt es halt, interessiert uns nicht.
Konstruktiv? Mitnichten!
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Es ist ja richtig, dass mit dem Fallback ist so nicht "optimal" und ein Bug. Und natürlich ist nicht der User an dem Bug schuld, ich sage nur, dass er eben nur User betrifft die eine neue Sprache aktivieren ohne alles notwendige übersetzt zu haben.

Dein Argument von wegen "neue Märkte" und Stück für Stück ist mMn falsch. Dafür gibt es Entwicklungsumgebungen die keine zu großen Mehrkosten verursachen.

Bei uns gibt es dev (dot) viverni (dot) com welches sich mit dem selben DB Server wie der Live- Shop verbindet aber dort die Datenbank dev_ statt der DB www_ anspricht. Änderungen werden dort gemacht, auch neue Sprachen und Co. und dann an die Git-Repository übernommen. Für Änderungen an Einstellungen/Sprachvariablen/Plugins/usw... hab ich mir ein Plugin geschrieben mit welchem ich auf Knopfdruck alles oder einzelne Teilbereich von der DB aus dem Testshop in den Liveshop bekomme (Aufwand auch vl. ein Arbeitstag für die Erstellung des Plugin). Wenn ich nun einen " stable" Status erreicht habe rufe ich Jenkins auf (muss einmalig eingerichtet werden) und am Live-Server passiert folgendes:

- Nginx wird beendet
- Alternative Nginx Konfiguration wird geladen (hat nur eine HTML Seite als Default mit Wartungsseite) und gestartet
- Änderungen werden von GIT-Repo übernommen (auch Änderungen an Nginx)
- Nginx wird wieder beendet, Config für den Normalbetrieb geladen und gestartet
- Ein Minify Script wird ausgeführt und erstellt einmalig Dateien alla CSS.de.min.<deploynr>.css usw...
- Paar MySQL Queries werden ausgeführt um die DeployNr. als Templateeinstellung verfügbar zu machen, den Cache der Templateeinstellungen zu löschen, usw...

(ich schreib das hier so ausführlich, damit der ein oder andere sich vl. auch überlegt ob sich die EINMALIGEN Einrichtungskosten für solch einen Setup nicht lohnen würden)
Einziger Mehrkostenfaktor > MultiShopmodul zur Nutzung der Testumgebung.
Die zweite Shoplizenz über SP "Entwicklerlizenz" lösen (da ja ohnehin Entwicklungsshop)

Nun kann man Inhalte, Zahlungsarten, Versandarten, Sprachen usw... nach Lust und Laune vorab vollständig einrichten bevor diese im Produktivsystem live gehen. Auch Plugins und Co. sowie Shopupdates lassen sich so 1:1 wie im Livesystem mit den eigenen Produkten testen.

Natürlich ist das für "kleine" Kunden ein Overkill, aber für euch vermutlich zB der richtige Workflow um hier ordentlich arbeiten zu können. Bugfixes über SP stellen auch kein Problem da, da diese ja in GIT geaddet wurden und wenn der Shop 4.03 dann kommt erstmal überschrieben werden > und man dann in GIT eben wieder guckt oder vorab via WinMerge oder BeyondCompare, ob der Bugfix den erhalten bleibt oder in dem Release noch nicht enthalten ist.
Für Datenbankänderungen hat JTL mit der 4.03 von SQL Dateien die ausgeführt auf "Migrations Skripte" umgestellt, damit kann man die DB auf 4.03 updaten aber auch wieder auf "Knopfdruck" die Änderungen rückgängig machen.

Meine Aussagen beziehen sich ja nicht spezifisch auf dieses Thema (sry für das abschweifen) sondern im allgemeinen um die mMn teilweise falsche Erwartungshaltung der JTL-Nutzer kombiniert mit dem fehlenden Willen selbst Geld in die Hand zu nehmen um wirkliche vorne dabei zu sein (Natürlich nicht für Bugfixes aber im Allgemeinen. Ein paar Stichworte dazu: hreflang-Tags, Shema.ORG Markup, Googel Händlerverifizierung, AMP konforme Seiten für Newsbeiträge, ordentliche Support- / Ticketsysteme,...)
 

testjo

Sehr aktives Mitglied
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Wasss Hula auch meint mit einer "Live" Produktiv umgebung umsetzen in testumgebung da zu testen findet man nicht alles.
Auch soll man dies bei vieles als JTL KUnde eigentlich gar nicht machen müssen , für alle normale Shop und WAWI Funktionen dass ist sache für JTL!

Ist wen Orders und Kunden mit alles bereits in Produktiv Datenbank sind, die den Updates von anfang also seit Jahren immer mitbekommen haben, dabei teils dan BUGS, die ja oder nein ein inkonsistenz aufweisen können in DB oder anderer Fehler die man nicht 123 findet.

Weil ist nicht 100% gleich den Bestehende Kunden mit alle seine settings und past orders, zahloptionen / versand und und, dieser dan im testdb ein neuer paypal oder amazonpay order tätigen zu lassen.
Mehrsprachen im ein bestehende / updated "Live DB" ( auch wen test) zu erweitern, ist auch immer schwierig den jungfraulich von anfang an solches drin zu setzen/erweitern.

Wir Arbeiten auch mit mehrere Kopie, WAWI / SHOPS, fidnen aber auch nicht alles, oder man macht mit den Produktiv Update ein TYPPO passierd auch.
Eben wie den versionen / nr.s und Datum von JTL nicht aussagen dass es auch den 100% gleiche versionen sind. ;)
Also wen tested mit ein update v1.0.0.0 von 9-1-2016 man ladet die nochmal herunter alles scheint gleich ist es eben nicht. Haben die manchmal gemacht auch beim shop. ;)
 

boaa-group

Sehr aktives Mitglied
28. Dezember 2007
4.932
8
Thailand, Bangkok
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Wasss Hula auch meint mit Live testen findet man nicht alles.

Ist wen Orders und Kunden mit alles bereist in Produktiv Datenbank sind, die den Updates von anfang also seit Jaheren immer mitbekommen haben, dabei teils dan BUGS, die ja oder nein ein inkonsistenz aufweisen können in DB oder anderer Fehler die man nicht 123 findet.
Weil ist nicht 100% gleich den Bestehende Kunden mit alle seine settings und past orders, dieser dan im testdb ein neuer paypal oder amazonpay order tätigen zu lassen.
Das stimmt natürlich, da muss man dann in solchen Fällen händisch in der DB prüfen warum bei Kunde X dies oder jenes nicht geht.


Mehrsprachen im ein bestehende / updated Live DB ( auch wen test) zu erweitern, ist auch immer schwierig den jungfraulich an anfang an soclhes drin zu setzen.
Eben nicht, da die neue Sprache für den Testshop aktivierst > im Shopadmin alle Texte übersetzen (lassen) kannst. In der Wawi kannst du dann auch schon für den Testshop abweichende Beschreibungen URLs und Übersetzungen hinterlegen. (da fehlt dann noch ein Zusatztool um das für den Liveshop zu übernehmen - wenn es aber nur um neue Sprache geht, kann man dies gleich im "Global" Block richtig hinterlegen, da es e nur zum Testshop abgeglichen wird).

Das Ganze dann nicht mit Agentur sondern mit Freelancern zum Preis pro Stunde statt preis pro Wort ;) und schon ist es auch finanzierbar. Für Rechtstexte Händlerbund, gibt ne solide Basis für das gängiste bis auf Datenschutzbestimmungen je nach Shopsetup und Plugins.

Anyway, ich lass das Thema hier Mal in Ruhe, wir wichen sonst zu sehr ab. Wer weiter darüber "diskutieren" möchte, kann ja ein neues Thema starten.
 

testjo

Sehr aktives Mitglied
AW: Mehrsprachigkeit - Fallback auf Standardsprache ungünstig

Anyway, ich lass das Thema hier Mal in Ruhe, wir wichen sonst zu sehr ab. Wer weiter darüber "diskutieren" möchte, kann ja ein neues Thema starten.

Yep.
Zum Fallback und übrige MehrSprachen probleme, die sollte man als JTL KUnde nicht erst "bemerken" beim durch den JTL Kunden selbst testen egal ob Produktiv oder im Testumgebung, weil dieser BASIS testen ist eigentlich sache für JTL oder? ( IN jedenfall wen die selbe sagen Shop und WAWI sind und können Mehrsprachen)
 
Status
Es sind keine weiteren Antworten möglich.
Ähnliche Themen
Titel Forum Antworten Datum
Mit Wawi nur auf dem Server arbeiten oder auf Server-Client Betrieb umstellen? JTL-Wawi 1.8 1
Neu Umzug auf neue Hardware / PAD Einrichtung / Updates von JTL-POS 0
OTTO Rechnungen tauchen nur noch unter EXTERNE RECHNUNGENU auf Otto.de - Anbindung (SCX) 1
Neu JTL Rest Api auf 1.8.12.2 Schnittstellen Import / Export 3
Aufträge ausliefern - Auf Pickliste - geht nicht JTL-Wawi 1.8 1
MISSING_REQUIRED_ATTRIBUTE Der von Ihnen gepflegte Titel ist zu lang. Kürzen Sie die den Wert entsprechend der Zeichenbegrenzung auf '70' Zeichen.O Otto.de - Anbindung (SCX) 0
Neu Seriennummer auf Lieferschein/Rechnung User helfen Usern - Fragen zu JTL-Wawi 0
Stücklisten auf EK umstellen JTL-Wawi 1.8 0
Neu Template auf Grundeinstellung zurücksetzen Templates für JTL-Shop 2
Neu Ameise Export speichern auf FTP Server Schnittstellen Import / Export 3
Neu Shopware 5 Bilder werden nicht übertragen nach Update auf Wawi 1.7.15.6 Shopware-Connector 0
Neu Bestseller auf Startseite werden willkürlich angezeigt Allgemeine Fragen zu JTL-Shop 3
Neu Freiposition auf Pickliste lässt sich nicht picken, Packtisch Gelöste Themen in diesem Bereich 2
Neu JTL SHOP update von 5.2.4 auf 5.3.1 - DBupdater startet nicht das Datenbankupdate Installation / Updates von JTL-Shop 6
Neu Falsches Zahlunsgziel auf Rechnungen Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu Artikel auf Amazon Listen User helfen Usern - Fragen zu JTL-Wawi 4
Wie schalt ich den worker Client aus auf den Server wegen Update JTL-Wawi 1.8 1
Neu JTL Search funktioniert nicht seit Shopupdate auf 5.3.1 JTL-Shop - Fehler und Bugs 0
Skonto ausgeben auf Rechnung JTL-Wawi 1.8 8
Neu Drucken-Button auf der Artikeldetailseite Allgemeine Fragen zu JTL-Shop 0
Neu Datenmigration von anderer WaWi auf JTL-WaWi Starten mit JTL: Projektabwicklung & Migration 12
Rechnungen werden nicht mehr erstellt seit Umstieg auf Fulfillment JTL-Wawi 1.8 0
Neu Darstellung/Werte der Variantenauswahl auf Amazon anpassbar? Amazon-Lister - Ideen, Lob und Kritik 0
Gelöst Onepage Composer geht nicht mehr nach Update auf 5.3.1 JTL-Shop - Fehler und Bugs 2
Neu Die Shop-URL verweist nicht auf einen gültigen Shop! Shopify-Connector 1
Neu Inhalt/Menge + Einheit auf Auftragspositionen joinen User helfen Usern - Fragen zu JTL-Wawi 6
Neu Stückliste auf Lieferschein Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu Artikel im Warenkorb wird von 1 auf null runtergesetzt. Anstatt es zu entfernen wird es automatisch wieder auf 1 gesetzt Allgemeine Fragen zu JTL-Shop 6
Neu leeres Textfeld erstellen für einen Hinweis auf der Rechnung User helfen Usern - Fragen zu JTL-Wawi 2
Neu Ust-ID nach Land auf Rechnung anzeigen Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
JTL 1.7 Bestimmte reservierte Produkte sollen keinen Einfluss auf Bestand haben JTL-Wawi 1.7 0
Neu Auftrag verpacken druckt auf 2 Drucker RE aus / wo kann das eingestellt werden? Arbeitsabläufe in JTL-WMS / JTL-Packtisch+ 0
Textfeld auf Folgeseiten bei Angebotsvorlage JTL-Wawi 1.8 1
Neu Lieferadresse auf Auftrag, Rechnung usw. Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 0
Neu Migration Shopware 5 auf 6 mit JTL-Wawi ohne Datenverlust Shopware-Connector 1
Neu Datenumzug von Xentral ERP Software auf JTL-Wawi Schnittstellen Import / Export 4
Neu Artikel nach Übertragung von JTL auf geplant im Jahr 2030 WooCommerce-Connector 2
Neu Mehrsprachige Attribute werden nur auf deutsch an SW6 übertragen Shopware-Connector 0
Neu Angriff auf JTL-Shop ?Log file: Wrong ip Allgemeine Fragen zu JTL-Shop 2
Neu Paypal Plugin Version 1.2.0 läuft und 1.4.0. läuft nicht auf derselben Umgebung Plugins für JTL-Shop 0
Neu Was steckt hinter der Zahl von 53 Bildern auf Ebay bei Variationsartikeln (und einer unsinnigen Fehlermeldung der Wawi)? JTL-Wawi - Fehler und Bugs 2
Ich habe auf NOVA umgestellt aber PayPal funktioniert nicht Einrichtung JTL-Shop5 1
Neu beim Umstieg von unicorn auf SCX Bilder aktivieren Otto.de - Anbindung (SCX) 1
Neu Gewicht auf Rechnung (Artikelgewicht und Zusatzgewicht) Druck-/ E-Mail-/ Exportvorlagen in JTL-Wawi 1
Neu gelöst: Update von 5.3.0 auf 5.3.1 - Dateien hochgeladen - immernoch alte Version Gelöste Themen in diesem Bereich 6
Neu Wechsel WAWI Hosting von JTL mit RDP auf ecomDATA User helfen Usern - Fragen zu JTL-Wawi 2
Neu Nach Update auf 5.3 funktioniert das Video-Portlet für lokale Videos nicht Gelöste Themen in diesem Bereich 9
Neu Update auf v5-2-5 Gelöste Themen in diesem Bereich 3
Neu Nach Update auf 5.3 fliegen die Produkte aus dem Merchant Center JTL-Shop - Fehler und Bugs 0
Wo befindet sich das Feld mit der Information für "Zustandsbeschreibung" auf Ebay? JTL-Wawi 1.8 9

Ähnliche Themen