Nein, das ist schlicht falsch. Schau Dir meinen ersten Beitrag noch einmal an. Hier zeige ich eine Menüdatei und eine Sprachdatei auf, jedoch keine Aktionsdatei. Ich glaube das ist das grundlegende Mißverständnis.Jonas wrote: Genau das will ich auch(nur mit der Mögloichkeit auf mehrere Aktions-dateien, aber das geht aus früheren Posts nicht hervor)
Der Unterschied: Bei mir ist die Standard Aktionsdatei frei von sprachspezifischen Eigenschaften. Das vereinfacht die Wartung (ein (un-)schöes Beispiel ist die momentane Menü-situation. Hier ist für jede Sprache eine eigene Menüdatei nötig obwohl die Struktur bei allen gleich ist. Diese Redundanz ist auch bei Deinem Beispiel nicht mehr vorhalnden. Aber anstelle dessen taucht eine Neue in der Aktionsdatei auf, da Du hier die Lokalisierung einbringst. Die Aktionsdatei muss bei Dir für jede Sprache extra vorhanden sein.)
Was denn nun? Direkte Möglichkeit zur Eingabe hört sich nun wieder sehr nach sprachspezifischem Text an. Bringe am Besten mal ein Beispiel!Jonas wrote: Mein Vorschlag:
Eine offizielle Menüdatei, die nur die Struktur der Menüs enthält. Genau wie bei Dir auch.
Eine offizielle Aktionsdatei, in der die Eigenschaften der Aktionen verwaltet werden. Auch hier soll auf eine Lokalisierung verzichtet werden: Beschriftungen sollen aus der Sprachdatei geholt werden. Aber es ist auch die Möglichkeit zur direkten Eingabe von Beschriftungen möglich (für spätere erweiterungen).
siehe oben - mein erstes Beispiel zeigt meine eigentliche Idee, die ich auch nach wie vor für die Geeignetste halte. In dem zweiten Beispiel habe ich mich an Deinem Vorschlag orientiert. Er gefällt mit deshalb nicht so gut, weil hier in der Aktionsdatei drinsteht wo in der Sprachdatei der lokalisierte Text zu finden ist. Das halte ich im Grunde genommen für überflüssig.Jonas wrote: In Deinem ersten Beispiel hast Du sprachspezifische Eigenschaften in die Aktionsdatei gepackt, im zweiten nicht mehr. deshalb denke ich das wir uns auch hier einig sind. Einziger Unterschied: Du verwendest einfach Zahlen für verweise aud die Sprachdatei und alles was nicht reine Zahl ist wird direkt ausgegeben. Ich benutze einfach einen prefix LNG. Was nun einfacher zu parsen ist, also die Prüfung auf eine reine Zahl oder den Prefix weiss ich nicht. Wie es letztendlich realisiert wird, ist mir auch egal. Mit dem Prefix währen auch Aliase als Verweis zur sprachdatei möglich, wie Du sie im Menübeispiel verwendest, aber so wie zZ. die Sprachdatei aufgebaut ist spielt das keine grosse rolle. Also beleibt unterm strich kein wirklicher Unterschied in unseren Versionen. für die implementierung sind wir ja nicht zuständig
Das ist eine gute Idee. Es sollte eine Standard-Sprachdatei geben und eine mit benutzerdefinierten Texten. Das selbe für die Aktionsdatei.Jonas wrote: Die Aktionsdatei solle aber nur Aktionen enthalten die von Standart abweichen. So ist das Update auf neuere Versionen einfacher da die evtl. vom User geänderte Aktiondatei nicht mit einer neuen ersetzt werden muss. Alternativ hierzu käme die obengenannte 2. Aktionsdatei ins Spiel die alle Standards enthält und erst an zweiter stelle zu Rate gezogen wird, wenn in der User-Aktions-Datei kein Eintrag zu finden ist. Sie wäre auch als art Übersicht über alle vorhandenen Aktionen zu sehen.
ja mit Verzeichnisname ist sicherlich sinnvoll.Jonas wrote: Was mir wichtiger als der Prefix ist, ist, das in meinem Beispiel der Name des Verzeichnisses im Namen auftaucht, also bei Dir cm_userCD_dir-xy anstelle von cm_UserCD00123...
Wenn wir schon bei der Nomelklatur sind, was haltet ihr davon, cm_* für intern implementierte Aktionen zu verwenden und user_* für automatisch generirte? Also im Falle der Hotlist zB. "user_cd_Programme" (und erst hier bei mehreren eine Nummerierung starten)
Ich meine alle Aktionen sollten mit cm_ beginnen. Es reicht aus, wenn die Kommandos in unterschiedlichen Dateien stehen. Im Aktionsmanager spielt die unterschiedliche Herkunft keine Rolle.
Ich bringe jetzt noch einmal ein erweitertes Beispiel, damit sind dann hoffentlich alle Unklarheiten beseitigt. Es basiert auf meinem ersten Beispiel und wurde, auch mit zahlreichen Deiner Vorschläge, weiterentwickelt:
Menüdatei:
;Anstelle von POPUP wird CTG für Category benutzt.
[CTG_SELECT]
MENUITEM cm_spreadselection
MENUITEM cm_shrinkselection
[END_CTG]
Vordefinierte Aktionsdatei:
; Die Kategorien in Menü- und Aktionsdatei können die Gleichen sein, müssen aber nicht. Man kann in der Menüdatei neue hinzufügen oder welche aus den Eigenschaften der Aktionen in der Aktionsdatei benutzen.
[cm_SpreadSelection]
ID=521
Category=CTG_SELECT
[cm_ShrinkSelection]
ID=522
Category=CTG_SELECT
Benutzerdefinierte Aktionsdatei:
[cm_CD_Pictures]
ID=720
Category=CTG_GOTO
Icon=%WINDIR%\System32\Shell32.dll,127
;Wo definierst Du in Deinem Beispiel eigentlich die Command-IDs?
Vordefinierte Sprachdatei:
[CTG_SELECT]
Caption=&Markieren
Hint=Markieren
;Ich habe mich bislang bei Caption und Hint an Delphi gehalten. Da hier jedoch viel Redundanz drinsteckt, könnte man das vielleicht noch etwas eleganter lösen. Meine erste Idee: Hint fällt weg. Der Text in Caption wird auch für den Tooltip verwendet. Hierbei wird jedoch '&' weggelassen.
[cm_SpreadSelection]
Caption=&Gruppe markieren
Hint=Gruppe markieren
Description= Wählt, basierend auf einem Filter, eine Gruppe von Dateien und Verzeichnissen aus.
;Einer Beschreibung für jede Sprache - viele Benutzer stolpern über die englischen Erklärungen. Viel Arbeit für die Übersetzer. In der Übergangszeit (Description ist nicht definiert) kann man ja die Englische anzeigen oder auch den Wert aus Caption.
;Wie gesagt - unter Umständen macht es auch Sinn den Hotkey in die Aktionsdatei mitreinzunehmen.
Benutzerdefinierte Sprachdatei:
[cm_CD_Pictures]
Caption=&Eigene Bilder
Hint=Eigene Bilder
Hotkey=CAS+B
). Hat der Chinese jedoch in seinem Menü nur Identifizierer wie CTG_SELECT benutzt, reichen Englischkenntnisse vollkommen und Du musst die Menüdatei nicht verändern, sondern nur die Sprachdatei erweitern.
