thanks for your quick and detailed reply. I can imagine what it means to look through the translations to do corrections, for a non german speaking person. Despite our very complicated spelling and grammar. It became even more worse after the last spelling reform. Many words are now written differently, but as most germans refused to do that and even teachers for German language at school didnt want to teach german according to that reform. A compromise was made, you can write in both ways and its correct. also the Grammar. Thats the one point.
BUt you are totally right that we should focus on a technical translation. And that could be a bit challenging. when I started I tried to find out what the german word for the tools will be. In traditional way of pattern construction you use peace of paper, a pencil, some rulers, and a calculator thats it. So you dont have that variety of tool for connecting points as the connection is always a line. In the construction books I have you dont find that. And I tried to get free test access to the chargeabel construction programms that are on the market here. And even my Adobe illustrator that I use which you can use for pattern construction (if u like that) didnt have these technical terms.
But I think I will find a way to figure that out. So feel free to send me the files to my private email adress which is email@example.com.
I noticed that… especially when checking some translations in DeepL.
Most of the tools describe the geometry of the tool… in a shorthand nototation. The ui has a limited amout of space to use, and I’m trying to keep the name of the tool classes and xml tags to a minumum, … so we drop things like “the”, “a”, adjectives and the like, The basic format is [what does the tool draw], and what are the [inputs]. So we get tool names like Point - On Line, Point - On Curve, Point - Length and Angle. Which relates to what the xml tags are (or will be - still updating all that)… so we have for example < point>… with attribute type = “online”. Other tools preform a task… such as Export Layout - which are a bit more straight forward.
Then there’s basic ui stuff like labels… where I reworked all the dialogs to adjust better to the length of the label… specifically if a translation is longer than the English. For exaple in English we can just use Lineweight (a drafting technical term)… instead of saying Weight of the Line which other languages like French or Spanish will use – where now the length becomes an issue if the dialog was orignally based on the shorter english label. So as far as those grammatical usage, I’d be more interested that it’s consistemt in use. For example… before I started working on the app, you could find “Pen style”, “Line type” or “Type of line” depending on the dialog.
Just for the heck of it I checked the German translation for Lineweight in QCad, and it’s “linienbreite”… which in DeepL it translates to “Line width”.
Which is acceptable, but is semantically different from Lineweight. Lineweight is historically a drafting term, and implies more than just how wide a line is… it has to do with how much pressure (weight) you placed on the pencil - the more “weight” or pressure, the wider the line you get as well as how dark or opaque the line is. Of course with CAD these days it indicates the width or thinckness of the line. IMO I again prefer the use of the accepted technical terms. For example: we “draft” patterns, we don’t “draw”: patterns. Artists draw pictures. That’s why there are “draftsmen” and not “drawsmen” - which would be a totally non sensical word. Thus the use of “draft block”.
That being said… we could make the argument that the “Line” part in Linetype and Lineweight is implied and thus redundant where the line attibutes are simply Type, Weight, and Color.
@Douglas, @bernt , hello together, I just saw the posts and think I should intervene, the sickness of a line is not Breite in germany its Stärke.
al letter in Bold is thicker than in non bold , Breiter is larger, A line is a Linie and not a Strich.
A Linie can be everything between a milimeter or endles, a Srich is a short line. And the standard for Translation is the Duden for German language and the Oxford dicitionary. Well guys if you wanna do that, its fine for me as I have a fulltime job as Surgeon.
This are thre pattern making programms available in German amd emglish, I made the screenshots from the english. website. I could be helpfull to look there to find oud the translations. ohterwise it coudl happen that tialsor or Fashion designers who do construction will be amused about our designations.
its always Linienstärke esp as a technical term in CAD Systems, so dont do your research in that way as it will destroy the german translation, and believe me I did my homework very well as one of my friends works as certified Translator for english and frensh
I was just pointing out that the QCAD application uses Linienbreite, which as I pointed out translates in DeepL to Line width. That being said - My educational background is in Civil Engineering and then Technical Theatre - so I’ve been drafting for well over 50 years. Like I said I prefer to use accepted technical term(s)… in this case Lineweight. So I agree with you.
I think we’re good for now… @H.Naehmann is working on tranlating a handful of additions I recently made. Of course the translations will always need updating as new features are added to the gui. Also feel free to point out any missing translations or errors.
That being said, I can outline in a nutshell how the translations work. First of all translating the apps is independent of the platform other than the tools you use to edit the *.ts translation files. TS files are simply text files in XML format. They are best edited using Qt Linguist as the app helps to avoid introducing errors. Linguist is normaly packaged as part of the Qt environment, but is also available as a standalone. I know there is a Windows ver, but I have not checked for a Mac or Linux ver. The ts files can also be edited in any text editor. Normally the ts files are part of the source code, which one would fork the project on Github, and manage the ts files through whatever Git client and build environment is set up. So one has to have knowledge of working with Git, PR’s and such… plus be granted write permission to the repo. Also due to the fact there are translation tests that are built and run when Github builds the apos, you really need to be able to build the apps, and run the tests locally before making a PR - lest there be any errors in the translations that will prevent Github from building a release. That requires setting up a Qt account and installing Qt on one’s machine. In order to avoid all that for those not inclined, a ts file can be downloaded from Github or I can PM them the latest, edit the translations, send the ts back to me, and I can handle getting it merged into the project.