Since I just went through updating the Spanish translations, I figured it would be easier on my end to resolve the conflicts in merging the German translations. Please feel free to make any corrections. Also there are some translations I left “unfinished” open to review, as well as there are some new untranslated sources… some resulting from adding in the vwidgets folder that was missing from the translations.pro file. There will be a couple new translations needed from the pending PR that changes the gike extensions for the apps.
3 Likes
@Douglas , @csett86 , many thanks for the update concerning the german translation, I *m not sure if this message asking me to do the final corrections? If so. lert me know.
2 Likes
what a surprise, due to my regular work I just updated seamly 2 D a few min ago and found the German Surface, And yes, I looked a bit around and found some Typos and as I mentioned before inconsistant translations for the same word. would like to help to finish it.
3 Likes
Agreed… I did notice inconsistencies with word choice or grammer in some cases. I assume that to be the result of multiple translators. So yeah… if you see were it can be improved - have at it. I can send you the most recent ts file, as there’s all ready a few additional translations needed.
BTW - I had to fix hundreds of errors in the de_De.ts file to allow it to build, so just a bit of background. There is a set of translation tests that are made when the apps are built. The tests check for various errors in the < translations>'s. If when run the tests have any FAIL’s, it prevents the project from building on Githhub. I always suggest to use Liguist to edit the translations as it can help identify certain errors before saving a ts file, and saving a lot of headaches, but IF directly editing the ts xml, one has to be careful to not introduce errors.
So for some general do’s and don’ts… which applies to anyone wanting to edit translations:
Do Not perform a mass search and replace… it may translate text that should not be translated.
Do Not translate math functions (for now). It messes up the math parser. See above.
Do Not Translate HTML tags… like width or height. See above.
Do Not remove the type=“unfinished” attributes unless pretty sure the translation is correct and free of errors. See above
Do Not remove any argument placeholders as designated by the % char… such as %1, %2, etc.
Do Not (under any circumstance) edit any < source>'s… even if there are typos or unecessary [spaces] in it.
Do maintain the same beginning and ending punctuation as the source. If a sentence ends with a period, the translation must end with a period. If a source starts or ends with a [space] the translation must start and end with a [space]. If the source ends in a ), the translation must end in a ) … and so on.
Do translate Ctrl or Shift if the language calls for it - such as German.
Do pay attention to the < context> of a < source>… depending on the context, it may require a different translation.
Do pay attention to Capitalization.
Do take into account the nature of the applications and use translations appropriate for sewing and garment industry CAD.
2 Likes
@Douglas , 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 guido.loehr@web.de.
looking forward to support you. :c
2 Likes
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.
3 Likes
A nice site for searching a translation is www.linguee.de it will show several sentences with the word.
So I searched for lineweight and found the right translation Strichstärke. And some others wich apply to power lines and so on.
2 Likes
Thanks Bernt.
Currently it’s “Linienstärke”… but I’ll leave it up to you German speakers to decide what’s more appropriate. I’ll just do what I can to facilitate updating the tramslations. 
3 Likes
This site is using DeepL to translate. Which I have found to give more / better tramslations than Google translate.
3 Likes
This would also be possible but I would prefer the other. As long as nobody chooses Leitungsgewicht 
2 Likes
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.
3 Likes
For the thickness of a line, I would use “width” which would be translated to Breite.
With lineweight I would expect more changes than only the thickness, like darker color or an other type of a dashed line.
2 Likes
@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.
https://www.grafis.com/home-en
https://www.lekala.co/?lang=de
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.
v
2 Likes
@Douglas , sorry for my replay but I looked in linguea, which is definetely a bit not always up to date
but even there and also in 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
2 Likes
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. 
3 Likes
Sending the ts file to you as a PM here as the email address is not valid from my mail client.
3 Likes
I’m just adding another Don’t I came across updating another set of translations. Just doing this so I can copy these to a translations help on the wiki at some point.
Don’t put spaces in translations that are meant to be part of a variable name. For example I ran into this… which causes the translatiosn test to fail.
<message>
<source>Radius1ElArc_</source>
<comment>Left symbol _ in the name</comment>
<translation>Радиус1 Дуги_</translation>
</message>
Needs to be:
<translation>Радиус1Дуги_</translation>
I also updated the comments to be more accurate:
<comment>No spaces in translation and must end with the _ symbol</comment>
3 Likes
hello, I’d love to help with translations english → german, but I am totally lost on where and on what platform you all make these changes and submissions…
3 Likes
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.
3 Likes