DotNetNuke-Usergroup

Hallo Zusammen,

deutsche resx Dateien lassen sich in VisualStudio 2005 nicht öffnen, resx Dateien aus anderen Sprachpaketen schon.

Das ist beim entwickeln sehr ärgerlich.

Ich wünsche mir zu Wheinachten ein deutsches Sprachpaket das ich auch in VS öffnen kann.

das solltest Du im Normalfall aber gar nicht müssen, selbst wenn Du bestehende Module anpasst oder im Core rumpfuscht, solltest Du bei der Entwicklung nur das englische Original direkt bearbeiten und am Ende einfach über den Übersetzungseditor im Host-Menü die deutsche Übersetzung anpassen - so stellst Du sicher, dass beide Versionen die gleichen Schlüssel bestzen.
Wenn es mal sein soll, kannst Du die Ressourcedateien aber in VS mit dem XML oder Text-Editor bearbeiten.

XML oder Texteditor empfehlen sich eh, weil der Resource-Editor die Einträge alphabetisch sortiert...

Und das lässt sich nicht abschalten, oder? Ein weiterer Eintrag in meiner Liste "warum ich andere Menschen schlicht und einfach beim besten Willen nicht verstehe". Ich würde ja meine Kleider von mir werfen, einen Besenstiel anspitzen und mich auf den Weg in die Wälder begeben, aber wie weit würde ich schon kommen...

Ich verstehe übrigens auch mitnichten, warum DNN-Leute partout einen eigenen Weg bei der Lokalisierung gehen wollen. Diverse Dinge funktionieren schon jetzt nicht mehr. Und wie immer wird es auf diesem Insel-Weg immer schlimmer und verrotteter werden. Manchmal bin ich so müde... Pfuscht heute eigentlich nur noch jeder?


(mk) (der trotz verzweifelter Bemühungen nicht schlafen kann - und der sich aufhängt, wenn wir die Türken nicht in die Soden zu den Würmern treten...)

Ich sehe es genau so wie Mathias.

Sebastian, "im Core rumpfuscht" ? Ich habe vorgehabt ein multilinguales Announcement Modul zu entwickeln. Da meine Muttersprache deutsch ist habe ich gedacht nimm doch einfach die Ressourcen vom Sebastian. Natürlich kann ich die Ressourcen mit einem anderem Programm öffnen und bearbeiten. VB Code kann ich auch mit dem Notepad schreiben und auf Befehlszeilenebene kompilieren. Aber ist das die Zukunft ?

Man kann ja heute schon viele Möglichkeiten von VS in Bezug auf Ressourcen in DNN nicht nutzen !!

Ich glaube das dieses Verhalten dazu führen kann das DNN technologisch den Anschluss verliert. Für mich ist/war das interessante an DNN das sich von der Idee her alle an die Syntax und die Möglichkeiten bei der Entwicklung orientieren die das Net.Framework und VS bietet und bei der Weiterenwicklung so bleibt.

Was sagt man heute dazu wenn der eine Browser XHTML anders interpretiert als der andere ? Da schimpft jeder darüber das der eine oder andere sich nicht an den Standard hält !!

Aus diesem Grunde denke ich immer öfters darüber nach ob es nicht einfacher und schneller ist eine vorhandene Anwendung aus VS insbesondere VS 2008 zu nehmen und in dieser Webparts zu entwickeln. Die kann ich auch in jeder beliebigen weiteren Anwendung importieren und installieren.

Ich arbeite mit DNN empfehle es meinen Kunden und entwickele Module dafür. Garade aus diesem Grunde übe ich diese Kritik.

Du hättest Dir natürlich einfach mal die "Mühe" machen können (wenn es Dich denn so nervt) durch die Dateien zu gehen und die "fehlenden" Ergänzungen bei jeweiligen Dateien machen ;-)

Ich habe mir diese mal für die aktuelle Version gemacht und stelle Dir und auch gerne dem Rest der Community sehr gerne zur Verfügung.

@Sebastian, wenn Du die Dateien möchtest melde Dich :-)

Hallo Stefan,

warum hast Du Dir die Mühe gemacht und die Dateien korrigiert ?

einfach so... wer weiß, gibt evtl. ja noch mehr Leute die das gerne hätte und nur nichts sagen. :-)

Ein paar Klarstellungen:

- Lokalisierung in DotNetNuke versus ASP.Net
- die DotNetNuke-Lokalisierung ist älter als die Lokalisierung in ASP.Net und hat daher einige Abweichungen
- da die Lokalisierung in DotNetNuke auch Features unterstützt, die ASP.Net nicht hat, wie das Anpassen der Sprachdateien je Portal oder Host ohne Überschreiben bei Aktualisierung der Basisdateien wäre eine Umstellung ein Rückschritt (ählich wie das Umstellen der Skins auf Masterpages).

- Prozess der Modulentwicklung
- Module entwickelt man mit englischen Sprachdateien, egal ob Anpassung von Standardmodulen oder eigene.
- Bei Bedeutungsänderungen eines Eintrags immer einen neuen Schlüssel verwenden.
- ShowMissingKeys in der Web.config hilft, fehlende Lokalisierungen aufzuspüren.
- Der Ressource-Verifier prüft auf doppelte Keys und listet fehlende oder lückenhafte Übersetzungsdateien
Anschließend erlaubt der Übersetzungseditor im Host-Menü ein schnelles, vollständiges und sauberes Erstellen/Anpassen der Übersetzung.

- Deutsche Sprachpakete
- Die deutschen Sprachpakete sind auf Größe und Geschwindigkeit optimiert. Durch Auslassen unnötiger Köpfe und Kommentare lassen sie sich nicht nur mit dem Übersetzungeditor, sondern notfalls auch schnell im Texteditor korrigieren - dies sind die typischen Werkzeuge eines Übersetzers.
- Das oben beschriebene Vorgehen wird dabei vollständig unterstützt.
- Auch wenn ich mich bei ein paar andersdenkenden Programmierern unbeliebt mache, bleiben meine Sprachdateien ausschließlich in diesem Format.
- Die von uns erstellten Sprachdateien unterliegen dem Urheberrecht. Anpassungen für persönliche Bedürfnisse sind zulässig, einer Veröffentlichung modifizierter Sprachdateien stimmen wir nicht zu.

Hallo Sebastian, selbstverständlich veröffentliche ich keine modifizierte Version der von Dir / euch veröffentlichten Sprachdateien ohne entsprechende Zustimmung!
Sorry Jonny, wenn Sebastian dem nicht zustimmt, kann ich Dir diese Dateien nicht geben. Du kannst das auch ganz einfach selbst erledigen, ist reine Fleißarbeit.

Hallo Sebastian,
das kann ich so leider nicht stehen lassen:

1.) die original englischen Dateien aus dem Core lassen sich ohne Probleme mit VS 2005/2008 öffnen. Dieses gilt auch für fast alle Module (kommerziell oder frei)
2.) Das Feature, dass die Dateien online ohne Überschreibung geändert werden können, ist ja wohl ein Feature des Editors bzw. der Programmlogik und NICHT der Dateien.
3.) Die resx Dateien beinhalten im Header einen großen Kommentarblock, der zugegeben überflüssig ist. Hier hätte es auch ein Verweis auf einen MSDN Artikel getan.
4.) Zusätzlich ist da aber noch ein XSD. Ein Schema zu entfernen halte ich grundsätzlich für unklug. Wie soll sonst sichergestellt werden, dass das was ich da vorgesetzt bekomme, auch korrekt ist ?? Die Frage hier ist, ob der Resourceloader dieses Schema nutzt oder nicht. In Visual Studio wird es ja wohl genutzt. Ansonsten könnte ich deine Dateien öffnen.
5.) Durch Hinzufügen dieser XSD's lassen sich deine Dateien wieder in VS öffnen. Somit hast du kein eigenes Format geschaffen!
6.) Der Übersetzungseditor lädt auch Dateien in denen Kommentare und XSD stehen schnell genug. Persönlich empfinde ich aber die Usability dieses Tools als katastrophal. Die Performanceprobleme sehe ich eher in der internen Archtektur und Aufbau dieses Tools und nicht als Problem der Dateien.
7.) Sich von den Vorgaben von Visual Studio zu entfernen ist schlecht und ja es wird dir einen Menge Diskussionen mit Entwicklern einhandeln. Ich persönlich werde die Vorgaben von VS in diesem Bereich nicht in Frage stellen.
8.) Selbstverständlich hast du das Urheberrecht auf deinen Teil der Dateien. Die Frage die sich mir aufdrängt ist aber, unter welcher Lizenz laufen deine Dateien ???
DNN ist nach einer BSD ähnlichen Lizenz lizensiert. Soll heißen OPEN SOURCE ! Wenn ich daran was ändern will, kann ich das unter Beibehaltung von Copyright Hinweisen usw. tun. Wenn du einer Modifizierung durch die Community nicht zustimmst, untergräbst du damit den OpenSource Gedanken. Da du bei dem Umfang der Übersetzung mit Sicherheit auch mal Fehler machst (niemand ist perfekt), wäre hier doch gearde ein schöner Ansatzpunkt. Wenn deine Dateien nicht unter BSD laufen, würde mich mal interssieren, wie du es siehst, dass es eine Menge von kommerziellen Projekten gibt die deine Dateine benutzen und angepasst haben. Sind jetzt alle diese Projekte illegal ???

Wie du siehst ist deine Argumentation ziemlich wackelig und erweckt bei mir den Eindruck, du willst dir ungerechtfertig Vorteile verschaffen. Ich hoffe du überdänkst deinen Standpunkt nochmal, da du sonst der Community schadest.

Mit freundlichen Grüßen

Jürgen Sommer

Korrektur zu Punkt 1)

Viele Dateien wie GlobalResources.resx und SharedResources.resx oder sämtliche Dateien unter Admin\Users\LocalResources lassen sich ohne Probleme öffnen.
(Getestet mit VS 2008 und DNN 4.8.3)

Ich möchte zunächst Sebastian dafür danken das es das deutsche Sprachpaket überhaupt gibt. Denn ohne Ihn würde es nicht viele deutsche DNN Portale geben.

Alle anderen sehe ich als eine Sache des Anspruchs und der Philosophie.

Ich vertrete die Ansicht das sich ein Portal/Anwendung nur dann mit voller Kraft entwickeln kann wenn deren Methoden und Eigenschaften sich zu 100% am Entwicklungswerkzeug der verwendeten Plattform richten.
Denn jede Ausnahme in der Anwendung ausgehend von einer Unzulänglichkeit der Entwicklungsumgebung erhöht den Lern.- und Wartungsaufwand sowie die Entwicklungszeit daraus eine auf den Anwender zugeschnittene Anwendung zu erstellen.

Sabastian ich kann nur versuchen Dich zu überzeugen. Ich würde mich sehr freuen wenn ich diese Dateien mit VS öffnen könnte.

So nebenbei mal was anderes, wo es mir gerade auffällt. Habe den Haken "Ich möchte benachrichtigt werden, sobald jemand antwortet Abonnieren" gesetzt, bekomme aber nie eine Mail vom System, ist da evtl. was "schief"?

Hallo Jonny,
o
> Alle anderen sehe ich als eine Sache des Anspruchs und der Philosophie.

Seh ich ein wenig anders.

Das nicht einhalten von Vorgaben hat entweder was mit fachlichem Unvermögen bzw. Unwissen zu tun oder mit bewusster politischer Enflussnahme.

Wie es hier in diesem Fall aussieht ist noch nicht abschließend geklärt.
Ich tippe aber auf letzteres. Ich verweise hierzu auch auf Streitigkeiten mit H.P.Schelian die u.a. auch um die Sprachpakete gingen.
Dauzu kommt eben auch, dass viele Originaldateien vom Core sich ohne Probleme öffnen und editieren lassen. Scheinbar hat man dort erkannt, dass
die Veränderungen der Dateien Blödsinn und technisch nicht zu begründen ist, auch wenn evnt. höhere Ladezeiten enstehen.

Grüße

Jürgen Somm

Dem Dankeschön an Sebastian für die viele Arbeit mit den Sprachpaketen schließe ich mich einfach einmal an. Da steckt immerhin einiges an Arbeit drin.

Kann auch durchaus verstehen, wenn Sebastian sein Recht selbst zu bestimmen, was mit seinem geistigen Eigentum passiert wahrnimmt. Es ist ja nicht gesagt, dass es nicht zukünftig auch weitere Projekte gibt, die solche Sprachpakete erarbeiten und anbieten! Diese dürfen nur nicht auf der Arbeit von anderen beruhen, sondern müssen eben bei Null anfangen. Ein Urheberrecht auf die deutsche Sprache und einfach feststehende Begriffe gibt es ja nicht :-)
Solange man nicht einfach die Dateien kopiert und als seine eigenen ausgibt ist das ja im legalen Bereich.

Wir haben auch schon für einige Kunden eine komplett eigene Übersetzung erstellt, anstatt die von DeutschNetNuke zu verwenden. Vielleicht werden wir diese auch mal als Basis für eine neuere Version nehmen, diese mal aktualisieren unter www.dnn-experten.de oder an anderer Stelle veröffentlichen. Muss ich mal mit den Partner besprechen.
Bevor es wieder den "üblichen" Einwand bezüglich der "Qualität" der Übersetzungen gibt, für die Erstellung konnten und können wir sicher wieder einen Kontakt zu mehreren Leuten vom "Fach" (aus dem Bildungsbereich, deutsche Sprache/Rechtschreibung etc.) nutzen, so dass die Qualität an dieser Stelle entsprechend gewährleitet ist.

Wer Interesse an solche einem "alternativen" Projekt hat, melde sich einfach bei mir oder einem der anderen Partner der dnn-experten (www.dnn-experten.de).

Zwei Dinge.

Das Nichtbearbeiten non Sebastians RESX Dateien in VS is ärgerlich aber offenbar nicht zu ändern. Der Workaround ist die rechte Maustaste und der Menüpunkt "Quellcode", dann kann man die XML Version bearbeiten.

In der Tat wird man aber doch für ein eigenes neues Modul ohnehin neue Resx Dateien verwenden und eigene Keys eintragen, in sofern kann sollte man dieses Ärgernis leicht herunterschlucken können.

Defacto nutzt das Core die Header seit einiger Zeit nicht mehr, dass sie in den englichen Dateien noch enthalten sind, ist evtl. schlicht Bequemlichkeit. Der Performancevorteil durch das Entfernen der Header ist in jedem Fall zu vernachlässigen. Die Header für eigene Projekte wieder einzubinden ist im übrigen in jedem besseren Texteditor /Respektive in VS selbst) per Suche / Ersetzen eine Sache von 1 Minute.

Ich verstehe einfach nicht, warum das Thema Resourcen immer wieder mal für hitzige Diskussionen sorgt. Hier hat sich einer die Mühe gemacht, die Sprachakete zu erstellen, zu organisieren und bereitzustellen. Das der Autor hierfür zumindest die Anerkennung erwarten darf, dass sein Copyrighthinweis nicht entfernt wird und auch nicht ein jeder eine abgewandelte Version der Pakete als eigene Übersetzungen vertreiben darf, versteht sich doch wohl von ganz alleine und ist alles andere als eine "wackelige Argumentation".

@Jürgen: Was soll der Hinweis auf OpenSource? DotNetNuke umfasst ein riesiges System von Drittanbietern, die kommerzielle Leistungen rund um das Produkt anbieten - untergraben die den Communitygedanken, weil sie Geld für ihr OpenSource Add-On nehmen? Womit verdienst Du Dein Geld?

Wenn sich jemand anderes mal die Mühe machen möchte, ein eigenes Sprachpaket herauszubringen, dann wird er sehr schnell festellen, dass das - jetzt mal ganz deutsch - saumäßig viel Arbeit ist. Wenn jemandem das die Mühe Wert ist - nur einer alternativen Lizenz wegen - dann soll er das machen [aber nicht schummeln :-)] Ich für meinen Teil bin sehr froh, dass es die Sprachpakete, so wie sie sind, gibt und dass ich sie in eigenen kommerziellen Projekten einsetzen kann.  Für mehr hätte ich auch echt keine Zeit.

OK, das waren wohl mehr als zwei Dinge.

Na ja, dass es zusätzliche Probleme mit den deutschen Resx-Dateien gibt, wusste ich noch garnicht. Ich habe mit eigenen gearbeitet und war einfach tödlich frustriert, dass die Übernahme diverser funktionierender Formulare sich zu einem Alptraum entwickelt hat. Zu der Tatsache, dass man einfach überall nur noch rote Kringel sieht (Validierung), kommt dann noch, dass man Bugs in der DNN-Insellösung umpopeln muss (mindestens CheckBoxList und Localize gehen nicht - weitere "Überraschungen" stehen sicher bereit).
Wer nicht schweigt, sondern sich zum Verteidiger der DNN-Lösung macht, riskiert halt Widerworte ;-) Ich bin ja mal gespannt, wie das mit DNN 5 weitergeht... Vielleicht schwenken die ja um, wenn sie sehen, dass es immer mehr Probleme gibt.

    (mk)

Also von meiner Seite aus nochmals ein riesen Dankeschön an Sebastian für die viele Arbeit, die in den Spachpaketen steckt. Da ich selbst etliche Sprachpakete für Dritthersteller Module anbiete und auch wie gesagt schon komplett eigenständige für den "Core" und viele Module durchgezogen habe, weiß ich was das heißt! 

Es scheint ja aber schon einige Leute zugeben, die sich an der "Lizenz" der Sprachpakete - aus was für Gründen auch immer - "stören". Das sollte zumindest eine Diskussion in der Community wert sein, wenn es immer wieder mal "hoch kommt". Welche Schlüsse man daraus zieht steht ja auf einem anderen Blatt. Vielleicht kann man zum Vorteil aller die Diskussion zu etwas positiven nutzen.

Ich persönlich fände ein Projekt sehr gut, welches vergleichbar den verschiedenen Projekten der "Core Module", deutsche Sprachpakete erstellt und diese dann z.B. hier für alle angeboten werden. Die Qualität lässt sich durch Reviews und "Guides" sicher halten oder weiter verbessern.

Eine Übersetzung einmal aus dem Boden zu stampfen ist das eine und sie von Release zu Release pünktlich auf den neuesten Stand zu bringen, das andere. Fast immer endet das damit, dass eine einzige Person sich erbarmt.
Es bleibt aber auch die Tatsache, dass mir noch kein Tool untergekommen ist, mit dem man vernünftige Übersetzungen machen kann. Da wäre es dann auch lohnender, wenn das universell für alle ASP.NET Applikationen einsetzbar wäre und nicht nur für DNN, bzw. wenn die DNN-Files wenigstens so korrekt wären, dass sie sich "normal" verarbeiten lassen.


   (mk)