Hey this thread is to discuss an issue with ‘Increments’, aka ‘Custom variables’
all right I found the source of the error, I referenced a thread from moniaqua, I put the URL of the thread and the URL produces the error.
How should I reference another thread?
Yeah it was a language translation issue which caused the variables to be named ‘increments’.
1 Like
So here is my entire message, without the URL that was causing the 500 error :
I often read about the word “increments”, I’m not sure why but until now I thought they were related to the multisize measurements (maybe because for me an increment is when doing +1 to a variable, as in $variable++ when programming. So another size would be like an increment of a base size. Crazy brain!).
Thanks to @moniaqua s thread I understand that they are in fact variables.
My question : up until now, when making a pattern for an accessoire, for a bag for instance, I used custom measurements for the height, the width etc of the accessoire. What is actually a best practice, is it best to use increments or custom measurements for this case?
The ease of a garment is probably better defined as a increments. Is that right?
I lean toward custom increments.
I want the measurements to be standardized on body measurements, and for all measurements to be included by default in all measurement files. This will make it pattern sharing and more complex operations using block patterns (more) possible.
2 Likes
I find there to be a few translation issues, but in any case to me anything that is measured should be (A TAPE) measurement, while anything that is a constant or variable should be an increment.
So yes… something like ease I would make an increment. Or another example… a ruffle fullness percentage - like 2 times, 3 times, etc.
2 Likes
Is there a third category of variable? There are body related measurements, multisize related “increments” and I have found no convenient place to store pattern design related variables. Examples of what I am calling design related include the amount of ease or the fullness of a ruffle or length (with regard to a body landmark such as the knee or ankle). I am throwing this idea out there in case anyone does any design or feature extension that could be affected by this. If I put it on the wrong thread I apologise. I am in a cruise terminal on Crete (not bragging at least not much) and for the next half hour have unlimited internet.
1 Like
Lucky you I hope you are enjoying it!!
Are the “increments” multisize related? I thought they were just variable and they could be used for your third category?
2 Likes
Increments can be used for what I describe as design related variables. Since I also have been working on some tutorials a d hope to do more on that when the dust settles I would find it easier to explain if the two were separated. But I can use it either way and explain it either way
I need to do some research on translation and terminology in various languages. In US English “increments” does not make sense as a place to hold design related variables but in other languages it may be different
That’s what I asked for in the thread @ronanletiec couldn’t link to 
Those variables I put in the variables table, but I have to do it for every pattern. I think I’ll just make “templates” of basic patterns and save them under a different name; after all I have to design the pattern out of the basic pattern anyways.
Do you have an example for “multisize increments”? I don’t do any multisize pattern, as I just work for myself, so I don’t know what is different there to a other pattern.
I’m 99% sure “increments” is just a bad translation of the Russian word for “ease” By the way @kmf and everyone else you can @ me for any questions about sewing terminology in Russian.
It would be also very useful to have some place for what I call “preliminary calculations” where I can make a variable for some things, say, sleeve width and calculate the value of it, so that final formula on the drawing would be more readable. It’s necessary to have access to data from the drawing for “preliminary calculations” like length of lines and similar
And my absolute dream is the “checkpoints” tab to check the length of corresponding lines. For example, I put there a line to compare armhole and sleevecap length and I can track in real time how this difference changes when I edit the curves. It might also have “intended difference” option and become red when actual difference is too far from the intended. I work with a lot of corresponding curves and now I just put lines in random places using formulas for the length of lines as checkpoints. It’s very messy and difficult to keep track of 
1 Like
Yes, that’s what I (try to) do in the variables table. For me the variables table gets constants, like ease, length of model and so on. Those stay the same in one pattern and are used (together with the variables) in formula.
I also have variables; those use the constants, other variables and measurements in formula.
Oh, it is not implemented yet? No wonder it didn’t work for me 
I tried to do that in the variables table.
I guess 
1 Like
This is called “walking a pattern”… where you can check that seams, armhole/sleeves, and “notches” (there is no such thing as “passmarks” - another bad translation) match. All the CAD programs have this feature… Optitex, Cameo, Gemini to name a few.
2 Likes
How about writing a wiki page listing the words that needs to be translated properly? Or do we have such a list?
1 Like
Here we go, a list of the terms that are wrongly being used in Valentina:
https://wiki.valentinaproject.org/wiki/Glossary#Vocabulary_Update
Feel free to update the list when another uncorrect term come to your mind!
4 Likes
Ahaha, I only just realized how “margins” became “fields”. That feeling when you think your English is BAD™ and then you see something like that
UPD If we are talking about translation then it’s definitely increments - ease. If we want to replace it with something broader, that’s another issue
1 Like
It’s not only the incorrect words there is also improper grammar… like “Lines angles”, “Lengths curves”, and inconsistency in word usage… like the use of “Line type” , “Type of line” , or “Pen style” as labels for the same property.
I got a better idea… instead of a wiki list, why don’t we just make the changes to the program? I’d be more than happy to make the corrections. Or should we wait another 4 years?
It should probably be something broader as “ease” only describes one specific way one could use those variables. Variables probably doesn’t work either as [Table of] Variables includes not only “increments”, but also line lengths, angles, etc.
1 Like
Right now the critics of bad choice of words is scattered across the forum. The goal of the list is to gather them, also make sure that we agree on the correct wording before implementing (like increments we still don’t know how we want to call it). That way we can also made all the changes as once.
Also the question is do we just update the terms in the GUI? Or throughout the code as well? I think we should do the later so that we have consistency.
Haha no we don’t want that and I agree that to much talking won’t bring us anywhere. I have a proposition, we start a thread for the bad wording, see if some people have other suggestion, complete the list and in a few day we can go for it and make the changes all at once. What do you think?
For that on the other hand there is no need for discussion in my opinion and can be changed right away!
What if we use “variables” instead of “increments” and find a new name for “variables table”. Like maybe “draft data” or something