Suggestion for improved naming efficiency

[odrnorn]

Hello everyone!

Recently a little „quality of life“-problem got a bit annoying to me:

In english, if you want the angle of lets say a line, the steps you have to do are the following;

-find the line

-find the name

-copy and paste the name into the „f(x)“-field

-write „degree“ in front of it

Sounds quite reasonable, right?

In german however, because of the capitalization of some words you now got to do the following every time you want a specific angle:

-find the line

-find the name -copy and paste the name into the „f(x)“-field

-write „winkel“ in front of it

-Until now nothing special-

-realize that the name of the line was capitalized

-try and get in between „winkel“ and „Linie“

-replace the „L“ for „l“

-realize the opposite is now required for „winkel“ (this should be capitalized) and do the same again

Sure this is a minor inconvinience, but a frequent one. (at least for me) And that got me thinking at how we can make the naming of objects more efficient;

Here is my idea;

-reduce capital letters -reduce writing work overall by shortening the names

the first point is easy to realise, but the second one can be dividet into two parts. The term is composed of 3 parts:

1. the part that tells us, what type of object we are referring to;

My suggestion: shorten it as much as possible. -“l:“ for lines -“s:“ for splines -“c:“ for circle

2. the part that tells us, what of those objects we actually mean My suggestion: shorten it to (for example) -“A10-A13“ if you want to take it even further you can decapitalize it to „a10-a13“ So a full term could be: -„s:a10-a13“

3. the part that tells us, if we mean the angle

I would shorten it aswell. For example to just „d“ or „d:“ for „degree“ So a full term could be: -„ds:a10-a13“ or „d:s:a10-a13“

AND a nice Idea that i had, was that the order of the points in the term determin which angle you mean. Let me explain with a picture:

When you go from A-B the degree would be „0“ but if you go from B-A, the degree is 90. this could reflect on the term: for example here it yould be „ds:a-b“ = 0 or „ds:b-a“ = 90 And since a line could also be described as a curve , changing the order just adds/removes 180

Let me tell you what you think of this idea, or how it can be improved thank you all for your work!

[Grace]

Hello, @odrnorn

Thank you very much for your suggestions.

@odrnorn

-realize that the name of the line was capitalized

When you are programming, you get different formats of joining words. What we use is called camel case (because of the hump in the middle) where the capital letter is in the middle and separates the 2 words, because you can’t use a space, like we do when typing normally and this is a format for naming things so that both the program and the person using the program can see what the object is. A further difficulty is that the names of the objects needs to be translated into multiple different languages… English, German, Chinese, etc., so it has to be something that can be translated and understood by experienced users and learners alike.

And then there’s the possibility that “dl” or “sl” could also be used as label and “c:” is already used as the shortcut to the main hard drive on a computer dating back to the beginning of computer-time.

Another consideration is avoiding anything that is used in calculations, formulas, functions or number formats, like + - / * , . ° % ^ : ? ( ) [ ] & | ; because these already have a dedicated task and the software will get confused and start calculating things that aren’t meant to be calculated or even crash because it can’t find the objects that it’s asked to calculate.

So, if I entered “ds:a10-a13” into a formula field, the program would see the : and think that you are entering a conditional statement and that you left out the 1st part of the condition which has the ? and then it would see the a10-a13 and think that you’re trying to subtract a13 from a10, and since these aren’t anything (only point labels), it will keep looking for them until the program crashes.

These are only some of the considerations that need to be taken into account when writing a program.

@odrnorn

AND a nice Idea that i had, was that the order of the points in the term determin which angle you mean.

LOL, I really like this idea, so I’ll leave it for @Douglas to explain. (I have an idea that it was discussed a long time ago.)

[Douglas]

@odrnorn

-find the line

-find the name

-copy and paste the name into the „f(x)“-field

-write „degree“ in front of it

Or you can just use the FX editor… To add a new line with an angle based on Line_A2_A3 click the FX button for the Angle formula. Select the Line Angles menu item to display and add line angles to the formula. You can filter the list… I filtered by A3:

I added the Angleline_A2_A3… then edited the formula with “+ 90”. pressing OK adds the formula to the formula in the dialog.

No pasting required. And it’s translatable:

@odrnorn

And that got me thinking at how we can make the naming of objects more efficient;

Appreciate the suggestions… but there’s more to how the object names are generated AND translated.

@odrnorn

the part that tells us, what of those objects we actually mean My suggestion: shorten it to (for example) -“A10-A13“ if you want to take it even further you can decapitalize it to „a10-a13“ So a full term could be: -„s:a10-a13“

I suggest you first undertsand how the math parser works. There’s a reason the “underscore” is used between point names… a “-” is the minus operation so A10-A13 would try to subtract A13 from A10… which would show as an error such as:

@odrnorn

I would shorten it aswell. For example to just „d“ or „d:“ for „degree“ So a full term could be: -„ds:a10-a13“ or „d:s:a10-a13“

There is no “degree” in the variable names… so I have no clue what you are referring to here?

@Grace

@odrnorn

AND a nice Idea that i had, was that the order of the points in the term determin which angle you mean.

LOL, I really like this idea, so I’ll leave it for @Douglas to explain. (I have an idea that it was discussed a long time ago.)

While it would be possible, it would require that when creating a new tool that adds a line, a 2nd variable would have to stored in the data container. Then some function would have to written to indentify the opposite of an angleline, then add 180 degs to get the “other” angle. Trust me… it’s easier for the user to just add “+ 180”.

[odrnorn]

Maybe this is a translation thing but in your picture you can see how in “AngleLine” both “Angle” and “Line” is capitalized. And in german “Winkelllinie” is only capitalized in the beginning, even though when I want to copy the name of that line it is “Linie” with a capital “L”, so I have to go back and change that every time. This is not a huge problem I know, but a frequent one. The easiest sollution might be to make “Winkellinie” to “WinkelLinie”.

The second idea was to shorten the whole expression. and yes I got the math problem but that was not what i wanted to referr to. Maybe one could do what I suggested with an underscore and “angle”, not “degree”: “AL_A1_A2” (AngleLine). But this was only if one really wants to make it shorter, and I understand that it might work against beginners, who benefit from the written out names. Maybe those systems could work at the same time? Then again, the data container would probably not like that, but as you figured, the technical details are not very well known to me.

[Grace]

@odrnorn

The easiest sollution might be to make “Winkellinie” to “WinkelLinie”.

I think this is a problem with the translation file. @Douglas, is there any way that we can check that?

[Douglas]

@odrnorn

Maybe this is a translation thing but in your picture you can see how in “AngleLine” both “Angle” and “Line” is capitalized. And in german “Winkelllinie” is only capitalized in the beginning,

Correct. That’s how the DE translation is.

@odrnorn

even though when I want to copy the name of that line it is “Linie” with a capital “L”, so I have to go back and change that every time.

I don’t get what you mean copy… copy from where?

@odrnorn

Maybe one could do what I suggested with an underscore and “angle”, not “degree”

There is no “degree” used in variable names.

@odrnorn

But this was only if one really wants to make it shorter, and I understand that it might work against beginners, who benefit from the written out names

The variable names have to be fixed in order to be translatable. Besides we can’t change the variable English names or it will break existing patterns. If you want to figure out to make your own translation file, have at it.

@Grace

@odrnorn

The easiest sollution might be to make “Winkellinie” to “WinkelLinie”.

I think this is a problem with the translation file. @Douglas, is there any way that we can check that?

There’s nothing to check.

“Winkellinie_” is the translation for “AngleLine_”.
“Linie_” is the translation for"Line_".

Just use the Formula Editor like I’ve already suggested.

If it were suggested to change the variable prefix “AngleLine_” to “LineAngle_” to be correct English… then I might listen.

[odrnorn]

“Linie” being the correct translation was not the issue. The issue is that it is written not capitalized. In english you can just write “Angle” in front and youd have the Angle but in german you first need to decapitalize “Linie” to “linie” beforehand. That was my issue

[Grace]

Ok, I was wrong in my earlier description because it only applies when 2 words are joined to make 1 word. In the case of German, the 2 words are actually 1 word already, so it doesn’t get the capital L in the translations. So because the correct translation is being used, yes, you will need to change the capital L to a lower case l.

[Douglas]

@odrnorn

“Linie” being the correct translation was not the issue. The issue is that it is written not capitalized. In english you can just write “Angle” in front and youd have the Angle but in german you first need to decapitalize “Linie” to “linie” beforehand. That was my issue

It is… I don’t see your point. The translation used IS "Winkellinie”. Here’s the source text in the seamly2d_de_DE.ts translation file.

<message>
    <source>AngleLine_</source>
    <comment>Leave the _ symbol in translation</comment>
    <translation>Winkellinie_</translation>
</message>

So if you’re having to decapitalize the “L”… I have no idea what the issue is? Again, using the FX editor is the prefered method of constructing formulas in the app. If you’re cutting & pasting from where ever, it’s not something we can control.

If it’s that big an issue you can always edit your own seamly2d_de_DE.ts file to translate how ever you want and then build the app.

[MG2024]

@odrnorn

In german however, because of the capitalization of some words you now got to do the following every time you want a specific angle:

This is online annoying if you are aware of the English names. In English is “angle line” two words in German is “Winkellinie” one word. I am not quite sure if it is handy to switch it to your suggestion. This could be confusing for German user, which only familiar with the German version and it would be wrong of the orthography.

Further as Douglas mention I do not get the point with copy in the fx-screen, just a double click on the selection is enough. In case that you tip the reference it is possible to use the English words in the German version, it will be also excepted.

@Douglas

Something what is not correct is the translation of SplPath = Splverzeichnis. A “Verzeichnis” is a register or list. SplPfad would be better. But as far as I got the point this is automatically generated. And if I would be really small minded; Spl means i guess split than would be the translation “Teil”. It follows that the correct translation of SplPath would be “Teilpfad”.

Honestly, who cares?

[Douglas]

@MG2024

Further as Douglas mention I do not get the point with copy in the fx-screen, just a double click on the selection is enough. In case that you tip the reference it is possible to use the English words in the German version, it will be also excepted.

The only thing I can think of is @odrnorn is copying a line length from another formula, pasting it in another formula, and adding “Winkel” in front of it? In which case you would end up with the Capital L from Linie… which we’re all in agreement on - includng the tranlslations - it should be Winkellinie. Or more specifically Winkellinie_ as translations have to end with the same punctuation as the English source. In this case “Line_”.

@MG2024

Something what is not correct is the translation of SplPath = Splverzeichnis.

Since I don’t speak German, and did not do the De tranlslations… I can’t say whether it’s correct or not…other than the translation is “SplVerzeichnis_”… which I can only assume the captial V should be lower case?

@MG2024

A “Verzeichnis” is a register or list. SplPfad would be better.

A quick look at Deepl… I would concur. Deepl’s top choice is Pfad. Also Deepl translates Verzeichnis as directory… so I’m guessing maybe Path got misinterepted as “file path” or a directory?

@MG2024

But as far as I got the point this is automatically generated.

It’s auto generated so to speak in the sense it takes the hardcoded (and translated) prefix, and appends the various point names. so for ex: given a line from point A1 to A2 it takes the prefix source or translation and appends the point names:

    <source>Line_</source>
    <translation>Linie_</translation>

“Linie_” + “A1” + “_” + “A2”… OR Linie_A1_A2.

@MG2024

And if I would be really small minded; Spl means i guess split than would be the translation “Teil”. It follows that the correct translation of SplPath would be “Teilpfad”.

Spl is an abbreviation for Spline. Which BTW abbreviations are BAD whe you need to translate, as they don’t always translate well. So it’s supposed to be Spline Path. I guess the orginal dev(s) thought SplPath would be shorter… not thinking that goes right out the window with other languages.

If the German users are in agreement I have no issue switching the translation to Splpfad_ or Splinepfad_. What we can’t do (without a headache for me) is change any of the prefixes like SplPath_ , Line_, etc… or we break existing patterns which will throw exceptions like:

[odrnorn]

@Douglas

The only thing I can think of is @odrnorn is copying a line length from another formula,

Yes, I usually copy it directly from the name of the object as states above

@odrnorn

-copy and paste the name into the „f(x)“-field

As a lazy individual I do this to spend less time searching for the correct name inside the editor. Hence my idea to shorten this up even further by being able to copy multiple names without copying each out of the property manager one by one. Not something that is crucial but annoying in the long term. (Idea for easy accumulated term building )

Further my laziness is disturbed by not being able to just write “Angle”/“Winkel” in front of it because of the translation.

But as a native german speaker I do completely disagree with the translation. Yes you might compound the words “Winkel” and “Linie” to “Winkellinie”, but this is actually more nonsensical then “WinkelLinie”. Let me explain: “WinkelLinie” can be understood as an abbreviation of “Winkel von Line” meaning “angle of line”. “Winkellinie” can EXCLUSIVLY be understood as “Line that is an angle”/“made out of an angle” wich is actually nonsensical as @Douglas stated earlier.

@Douglas

If it were suggested to change the variable prefix “AngleLine_” to “LineAngle_” to be correct English… then I might listen.

Correct would be in german as in english “Linienwinkel”, but “Winkellinie” is completely wrong, more so than “WinkelLinie”. But “Linienwinkel” would eliminate the ability to just copy the name and add “angle”/“Winkel” in front of it. So yes, this is a translation error. But a tricky one, so the confusion is absolutely understandable. (and an explanation why the automated translation didnt catch that since by syntax it is the correct translation, but semanticly an absolute nightmare)

[slspencer]

@odrnorn
It appears that the best we can do to alleviate some of the workflow overhead is to change “Winkellinie” to “WinkelLinie”.

CamelCase naming consistency is important.

[MG2024]

@Douglas

What we can’t do (without a headache for me) is change any of the prefixes like SplPath_ , Line_, etc… or we break existing patterns which will throw exceptions like:

I recommend to do it if you like to be the most hatted person in the community. This is to many headache for a tiny improvement.

@Douglas

Spline Path. I guess the orginal dev(s) thought SplPath would be shorter

The short way is quicker to typ. The word Spline exist btw also in German in numeric.

In general English is a compulsory school subject in Germany. Every German should be able to understand the English vocabulary used. And certainly if you out fashion, since almost all communication is conducted in English.

[odrnorn]

slspencer I think now that my (and probably many others) workflow is understood I´d like to rediscuss my idea Idea for easy accumulated term building .

As I said, I usually copy the name of a selected line by copying it from the description.

But here you can see just selecting/hovering over an object can tell the program what it is called.

What if you could copy the name/multiple names just by selecting the object(s)? Pls look at my post linked above to see my whole explanation/idea. This addition would help my lazy behind very much.

[MG2024]

@odrnorn

Not something that is crucial but annoying in the long term. (Idea for easy accumulated term building )

Ich verstehe deinen Punkt, es kann manchmal ganz schön nervig sein die Referenzen im F(x)-Monitor zu finden.

Wie ich schon vorher erwähnte ist es meist schneller, wenn man die Referenz eintippt. Du kannst einfach die englischen Namen nehmen, auch wenn die Einstellung auf Deutsch ist. Die werden akzeptiert und auch dann umbenannt.

Die Übersetzung wird auch nicht von den Administratoren gemacht. Ein integriertes Modul, wie bei jeder mehrsprachigen Webseite üblich, macht die Übersetzung. Auch Deepl schmeißt manchmal ziemlichen Blödsinn raus.

@odrnorn

as in english “Linienwinkel”, but “Winkellinie” is completely wrong,

Ich hätte auch gerne einige Sachen anders übersetzt, sicherlich bei den Namen der hinterlegten Masse. Da es automatisiert übersetzt wird, ist das eine sehr germanistische und philosophische Diskussion.

[odrnorn]

Ja ein grammatikalischer Punkt aber hier auch einer, der meiner Faulheit hilft. XD

Einfach die Sachen auf englisch einzutippen wird mir aber hier nicht viel helfen weil ich ja die Namen rauskopieren möchte um noch weniger Schreibarbeit zu haben. Vor einem rauskopiertem Liniennamen einfach “Angle” zu packen bringt mich dann nicht weiter.

[Douglas]

@odrnorn

Hence my idea to shorten this up even further by being able to copy multiple names without copying each out of the property manager one by one

Again… it’s just not a workable idea. The graphics scene doesn’t work the way you may think it does. Besides… the reality is there are other features on the roadmap that I have to work on rather than making for less typing / clicking for a few users.

@slspencer

It appears that the best we can do to alleviate some of the workflow overhead is to change “Winkellinie” to “WinkelLinie”.

CamelCase naming consistency is important.

I have no problem changing the translation… if others are in agreement.

I concur there’s a reason for using CamelCase as it’s easier to read, unless one were to use strickly use lower_snake_case - like as wtth the known messurement names. IMO the prefixes are part of the variable names, not words that need to be gramatically correct. And as I’ve pointed out we can’t easily change the English source, but the translations can be whatever we want as the application uses the English source texts internally and in the xml files, where only the GUI gets translated.