@emre, I would like to suggest renaming some properties and parameters in future versions, to make States less confusing and easier to explain:
State Name is Delivery Status and the State is Delivering. Is it really sounds confusing for English speaking people? I’m asking because we may think different because of the differences in our primary languages. I’ve also named state value as is to follow our common naming convention. Like Command Value.
On the other hand such renaming is too hard to accomplish as we store these as rule parameters. For example the issue with [:Value] in Gift status was a result of renaming Command's Value to Command Value. If we really should rename this we should do it with a major upgrade and we should rename other similar usages too.
That sounds very confusing to me 
(but then I’m not a native English speaker either)
I understand this is something hard to change and can cause problems with upgrading, so maybe don’t do it right now.
So I have another suggestion for the future: having some kind of ‘Upgrade module’ or something which can convert the database, taking these kind of changes into consideration.
I was just requesting this because I think States are already not such an easy concept to understand, and having these fields and parameters closer to human language would make that a bit easier.
I did put the alternative names in the States documentation, so it’s not really a problem, just saying it might be something you want to think about for in the future…
Should we follow Group > Name > Note pattern ?
State Group > State Name > State Note
Order Tag Group > Order Tag Name > Order Tag Note
Ticket Tag Group > Ticket Tag Name > Ticket Tag Note
We have a database update module and we can code something to loop all rules, actions and other possible places that should renamed. I mean it is possible but a lot of work 
Other than database upgrade we should also think past documentation & tutorials.
I think this is where a lot of the confusion comes from, and changing the Labels for the boxes would be easy and would go a long way to clearing up confusion:
That makes perfect sense to me and I am from USA. However I agree with @QMcKay we should change the labels he indicated because Users see Group Code when defining a State and then when they use an Action to assign that State they do not even see Group Code listed at all because it is actually labeled as Entity State Name.
When defining a State from Settings the label of Name: is not as big of a deal but It should probably be changed to State just for consistency.
I’ve labeled Group Code as State Name. Let’s use it for a while and if it still needs a change we can fine tune it.
@QMcKay editing an action parameter name is not just a labeling issue. You know we reference it via [:EntityStateName] tag and if we change it we should also change all references. If we only change labeling we should always remember we’ll access Group Code parameter with [:EntityStateName] tag.
Also the reason I’ve prefixed it with Entity keyword is differentiating them from other states (order, ticket). As these parameter value lists are auto generated it makes implementation just easier. This is how my code appears.
So renaming [:EntityStateName] to [:GroupCode] will also create other issues for me.
Naming is the biggest issue while creating a dynamic infrastructure because we’re also using human language as a programming aspect. I’m trying to keep both ease of implementation and end user language in balance.
I understand what you’re saying @emre … I knew there had to be a reason for the reluctance.
I don’t want you to need to change code all over the place; of course we want to avoid that. Here is another simple suggestion…
EDIT: I missed that part… I was afraid that might be the case. Ok I get it - it’s not a simple labeling change.
I’ll still leave this suggestion here in case you want to consider it in the future:
