Übersetzung ins Deutsche

[holdi]

Wenn also bei Würfel Breite steht, und ich in einen berechneten Ausdruck (Expression) Breite verwenden will, aber nur Width akzeptiert wird, habe ich ein ziemliches Benutzungsproblem.

Leuchtet mir nicht ein, weil der Benutzer gar nicht das Wort Breite sondern eine Zahl (mit a.a. Ort gewählter Längeneinheit) für die Breite eingibt oder verändert. Das Programm hat eine Zahl für meinetwegen die Größe width zu verarbeiten. In einer deutschen Version darf man m.E. getrost einen Dialog mit dem Wort Breite vor diese Zahl führen.
mgG holdi

[chrisb]

Wenn man in einem Ausdruck (oder auch in Python) Bezug nimmt auf die Breite, dann verwendet man Cube.Width, und das sollte auch so bleiben und nicht übersetzt werden. Eine Übersetzung hier führt zu Unübersichtlichkeiten, die wir uns echt nicht antun wollen. Auch Skripte würden dann nur noch in der Sprachumgebung laufen, in der sie geschrieben wurden.

[r.tec]

just my zwei Centinos:

den Begriff "Box" mit Würfel zu übersetzten ist mMn auch gewagt, denn ein Würfel hat die gleiche Kantenlänge überall. Eigentlich wäre Quader die richtige Übersetzung, aber ich wage zu behaupten, dass 80% der derzeitigen Abiturienten mit Quader überhaupt nichts anfangen können...

[holdi]

den Begriff "Box" mit Würfel zu übersetzten ist mMn auch gewagt, denn ein Würfel hat die gleiche Kantenlänge überall.

Warum diese Nebenbemerkung? Es geht doch noch lange nicht um ein bestimmtes deutsches Wort für z.B. die englische Box, die nach ulrich1a's und chrisb's Meinung quasi wie von Gott gegeben unausweichlich immer auf dem Bildschirm erscheinen muss. Was ist Deine Meinung zu dieser vorgeblichen Zwangslage? Kannst Du nachvollziehen, was hier zwei Programmierer vertreten?
Nachtrag: Du verwechselst den Dialog-Begriff Box mit dem "primitiven" geometrischen Körper Cube.

ulrich1a und chrisb,
anbei noch ein das obige ergänzende Bildschirm-Foto mit Python-Text. Dieser Programm-Teil mag so funktionieren. Es leuchtet mir aber nicht ein, dass hier im Vordergrund (im Dioalogfeld !! ) auf den Buchstaben genau gleiche Wörter wie im Hintergrund (Python-Text: .getObject .Length = !!) stehen müssen. Noch einmal (s.o.): Der Benutzer schreibt z.B. 20 , nicht "Box" .Length = '20 mm' .

Ihr drei,
da ich meine, noch nicht aufgeben zu müssen, würde ich gerne mit crowdin weiter kommen. Wer von Euch hilft mir bitte (vorerst .ts-Dateien lesen zu können)?

mfG holdi

[ulrich1a]

Kannst Du nachvollziehen, was hier zwei Programmierer vertreten?

Hier geht es nicht nur um Programmierung, sondern um die Nutzung der parametrischen Konstruktion mit Hilfe von berechneten Ausdrücken. Siehe Hier: http://www.freecadweb.org/wiki/index.ph ... xpressions

Bei diesen "Expressions" kann man ein Maß in Abhängigkeit von zum Beispiel Cube.Length definieren. Die Eigenschaft ".Length" ist dabei fest in FreeCAD vorgegeben. Das geht mit der Benutzeroberfläche ganz ohne Programmieren.
Hier ein Beispiel mit den sichtbaren Formeln.

Ulrich

[r-frank]

da ich meine, noch nicht aufgeben zu müssen, würde ich gerne mit crowdin weiter kommen. Wer von Euch hilft mir bitte (vorerst .ts-Dateien lesen zu können)?

Hab Dir extra auf Youtube ein Video zur Erklärung hochgeladen ...

[herbk]

Hi Holdi,

Es leuchtet mir aber nicht ein, dass hier im Vordergrund (im Dioalogfeld !! ) auf den Buchstaben genau gleiche Wörter wie im Hintergrund (Python-Text:

Ich habe auch nicht wirklich viel Ahnung vom Programmieren, aber dennoch denke ich dass ich nachvollziehen kann weshalb das so ist und auch nicht so ohne weiteres verändert werden kann.

(Python-Text: .getObject .Length = !!)

ruft (m.E.) den Wert ab den Du im Feld neben Length eingibst und weisst der Variablen "Length" diesen Wert zu.
Das ungünstige dabei ist, dass das was Du in dem Feld siehst die tatsächliche Variable ist und nicht ein "GUI Name" für diese. D.h.: getObject holt sich nicht nur den den Wert den Du eingibst aus der Maske, sondern aus dem Feld links davon auch den Namen der Variablen. Wenn Du den jetzt änderst (übersetzt), finden alle Formeln die mit Lenght rechnen wollen eines ihrer Argumente nicht mehr.
Um das zu verhindern muss die Arbeitsoberfläche (GUI, - das was man sieht) vollständig von dem "was im Hintergrund abläuft" getrennt werden, was aber ohne größere "Umbauarbeiten" nicht machbar ist.

So hab ich das zumindest verstanden...

[holdi]

So hab ich das zumindest verstanden...

Ich inzwischen auch, aber warum muss jemand neben mir stehen, wenn ich ihm etwas sagen will. Ich kann z.B. telefonieren, also über ein Zwischending kommunizieren. Dieses Ding macht nach Deiner und Meinung Anderer größere Umbauarbeiten erforderlich. Na wenigstens ist jetzt klar, dass ich nicht Gottgegebenes "angreife". An und in FreeCad werden Hunderttausende von Dingen getan, unter denen einige nutzlose sein könnten, an deren Stelle nützliche hätten oder könnten noch getan werden, wie das vorliegende Ding z.B.

Hier ein Beispiel mit den sichtbaren Formeln.

Du hast hierbei mit der Spacheinstellung English gearbeitet. Bei der Spracheinstellung Deutsch hat bei mir die Sache nicht funktioniert.
Abgesehen davon, dass solche Expressions m.E. zu aufwändiges Schreiben von Programmzeilen in der Python-Konsole erfordern, keine Vorformulierungen vorliegen, erkannte ich bereits in Fehlermeldungen meiner gescheiterten Versuche Unsinniges: Unnamed wurde nicht akzeptiert, es musste Unbenannt (also doch Deutsch) sein. Hingegen war weder mit z.B. u'Cube.Height * 2' (English) noch mit u'Würfel. Height * 2' (teiweise Deutsch) weiter zu kommen. Das zu meiner obigen Bemerkung ... nutzlose sein könnten, ....

mfG holdi

[holdi]

Dies alles sollte jedoch die Übersetzung des Buches von Yorik nicht verhindern.

Vielleicht sollte man das Buch einfach um ein Glossar ergänzen, in dem solche Begriffe erklärt werden.

Yorik hat m.E. alles nieder geschrieben, was er nicht nur über FreeCAD sondern über CAD und und dessen Umfeld insgesamt weiß. Eine Gesamtübersetzung findet sicher ihre Leser. Ich selbst halte den Bedarf an einer zusätzliche Teilübersetzung für pure Benutzer von FreeCAD (neue, gelegentlich damit arbeitende, nicht mitentwickelnde) für größer. Diese puren Benutzer brauchen m.E. nicht nur eine Übersetzung der alltags-englischen Anteile sondern der Fachbegriffe, die dann auch konsequent beim Programmgebrauch zu erscheinen haben. Ein solcher purer neuer Benutzer war ich auch (und bin es in größerem Grade immer noch). Ich bin weiterhin über die Nutzerunfreundlichkeit der deutschen (zutreffender: denglishen) Version erbost, weshalb es nicht relevant ist, dass ich mich mit schlechten Gründen in irgend einer Form (Glossar, Klammer-Begriffe o.ä.) an der Verteidigung dieses Zustands beteilige.

mfG holdi

[chrisb]

Du hast hierbei mit der Spacheinstellung English gearbeitet. Bei der Spracheinstellung Deutsch hat bei mir die Sache nicht funktioniert.
Abgesehen davon, dass solche Expressions m.E. zu aufwändiges Schreiben von Programmzeilen in der Python-Konsole erfordern, keine Vorformulierungen vorliegen, erkannte ich bereits in Fehlermeldungen meiner gescheiterten Versuche Unsinniges: Unnamed wurde nicht akzeptiert, es musste Unbenannt (also doch Deutsch) sein. Hingegen war weder mit z.B. u'Cube.Height * 2' (English) noch mit u'Würfel. Height * 2' (teilweise Deutsch) weiter zu kommen. Das zu meiner obigen Bemerkung ... nutzlose sein könnten, ....

mfG holdi

Ich verstehe ja, dass Dich ein deutsch-englischer Misch-Masch nervt und ich bin auch stets für eine präzise und klare Verwendung von Sprache jederzeit zu haben. Bei FreeCAD ist das allerdings nicht so einfach, und das hat verschiedene Gründe:

• FreeCAD ist ein internationales Projekt, da ist es derzeit gängig, Englisch als gemeinsame Sprache zu verwenden.
• Eine der Stärken von FreeCAD ist möglichkeit Makros zu verwenden (oder allgemeiner: Python-Programmierung).
• Eine der Stärken von FreeCAD ist die Verwendung von Ausdrücken
• Ein wesentlicher Teil von FreeCAD ist die hier im Forum versammelte internationale Gemeinschaft.Da möchte ich verstanden werden und verstehen.

Nun stellt sich die Frage nach dem Ziel: Geht es um die einheitliche Bezeichnung an sich oder ist die nur Mittel zum Zweck einfacherer Bedienung. Wenn es um Letzteres geht, dann müssen wir möglicherweise einen Kompromiss finden zwischen einem besonders einfachen Einstieg und der einfachen Bedienung für Fortgeschrittene. Mir geht es bei FreeCAD in erster Linie um die Benutzbarkeit und da sehe ich mehr Vorteile, wenn man die Begriffe, die man in Ausdrücken verwenden kann, an der Oberfläche genauso bezeichnet wie im Ausdruck.
Ich könnte mir noch ein Zwischending vorstellen, bei dem der eine Teil fest im GUI steht, der andere in einem Mouse-over-Text oder auch - wenn der Platz da ist - in Klammern dahinter.

Ein abschreckendes Gegenbeispiel ist die Verwendung von Formeln in Excel: Dort wurden auch die Funktionsnamen ersetzt und das führt bei der Verwendung verschiedensprachiger Installationen regelmäßig zu echtem Stress, daher mein erster Einwand, dass wir uns das nicht antun sollten.

Nun noch etwas zu den Ausdrücken:
Die Ausdrücke erfordern überhaupt keine Python-Konsole und sind auch überhaupt nicht nutzlos. Man kann an fast allen Stellen, an denen Maße eingegeben werden können, auf andere Maße zurückgreifen. Das macht die Modelle wesentlich robuster als die Verwendung externer Geometrie und bietet auch noch weitere Möglichkeiten, weil die Maße als Bestandteil einer Formel verwendet werden können, während externe Geometrien nur so verwendet werden können wie sie eben sind. Man könnte die Ausdrücke als "Tabelle für Arme" bezeichnen.
Das Beispiel funktioniert natürlich nur, wenn Du die Bezeichnungen Deines Dokuments verwendest.