Come on gang, let's take the piss out of Holy Diver because that's how we roll!!

[Holy_Diver]

I was planning on posting a similar topic before finalizing a translation update, but I'm working on translating the sample project to include in the new patch so I hadn't gotten to it yet. Obviously, since I did the translation, I've already weighed the pros and cons in my own opinion (I consulted others too) and the result is reflected in the current translation. Quite a few people have learned how to use SoM with little or no manual reference so I think there is some evidence suggesting my choices were fairly clear.

Well I think there should be an attempt at consensus so to avoid the prospect of competition between translations. I could've learned to use SOM just as quickly if all the words were nonsense (which I suppose Japanese might appear to be to some people) but I think the evidence of confusion about the forums indicates that people aren't really getting it. Unfortunately a process like SOM isn't very natural no matter how you cut it, so in the long run using clear/unambiguous terms is probably best for everyone.

I think it's important to stay away from terms that aren't familiar to average people (like programming terms) which is why I changed 'IF ELSE' to 'IF OTHERWISE'.

IF ELSE and OTHERWISE are standard programming syntax. Technical terms are actually different from syntax. Usually programmers and such speak in technical terms so to be syntax neutral except when specifically addressing syntax. With SOM I don't see any reason the two can't be the same however.

My view on specific terms:
'Leaf' does not just refer to trees; it also means 'page or section' as in the leaves of a book or a table leaf. In SoM a Leaf is one page in an Event 'book'. The 'Active leaf' is the one currently being read (aka having its commands carried out). I think 'Page' might have been better than 'Leaf' (leaf was the literal translation), but having a unusual term helps prevent term confusion like there is with Object, Part, Piece etc. My vote is either 'Leaf' or 'Page'.

Leaves of a book is archaic language. Stage is much more clear. If someone sees page it's hard to wrap your head around what that might mean. Especially if they read it in a forum. Stage is very clear. Events have stages anyway, not pages, better to be literal... I mean why not call events books then? I'm not on the attack, I just want to reach a middle of the road consensus with the biggest priority being avoiding misunderstanding and meandering assistance threads in the help forums.

Events are completely free-standing and self contained- not part of a tree or such, so calling them an 'event leaf' seems needlessly confusing and inaccurate. If there is some other word that means 'a thing that makes stuff happen' it could be changed but 'Event' seems clear to me. My vote is for 'Event'.

Events aren't free standing, they're applied to an object npc or enemy, which itself is applied to a map square. That's a tree, and events are always leaves in that tree (for now) ...that said I didn't say we should call Events "Event Leaves", though that would be appropriate language when describing to someone the layout of hte piece setup window. We should just call them EVENTS and drop LEAF altogether.

'Instructions' to me means 'I'm telling someone else how to do something and they may or may not do it'? whereas 'command' means 'I'm telling someone to do something that will be done'. Therefore I think 'Command' is more clear. For instance, if a 'command prompt' was called an 'instruction prompt' wouldn't it be more vague?

There is no such thing as a "instruction prompt". Commands are part of a script and can be loosely interpreted... each representing a program or pseudo program in and of itself. Instructions are what makes up program, like an add instruction. What the things are in the "event leaf setup" window are clearly instructions. Like a processor you buy for your computer has an instruction set, these are identical. Use of command and not instruction in this case is just incorrect by definition. These are clearly instructions.

'Counter' is a numerical term meaning 'one who counts' whereas 'Register' is generic term that could mean a lot of things. Register is also used elsewhere which would just lead to confusion. My vote is for 'counter' or some other term that specifically means 'a place where a number is stored'.

A register is memory where data is stored. A ram module you put in your computer is comprised of X amount of registers, each representing a memory address. In the exact same way each counter is a register holding some data. And each item number is a register holding an item's data.

The 'Register' button in the parameter editor specifically means 'add the selected to the Registry list'. The Registry list being the same-titled list on the left- thus differentiating it from the 'save' button which saves changes to already registered parts. I don't necessarily think 'Register' is the best term, but it's not bad either. If a different term is used, it should be something that means 'enter into the database'.

Well it's changing the contents of the selected register. So it's not technically being added or registered, even though the register could've previously been empty. Therefore it works just like the counters, even though it can't currently be changed at run-time. In other words it's being changed.

I think the important question is 'were there any terms that you found confusing while learning to use SoM' and 'could a different word have been used that would have made it easier to understand.' Inserting simple descriptions for confusing functions would be more worthwhile than splitting hairs over which single words to use as a label. Any single word is likely to make sense to some and confuse others.

Yeah, definitely... if the changes I've outlined were there the entire process would've been crystal clear / self documenting. But then I'm a professional. For people with no grasp of technical terminology, anything will do, but it doesn't hurt to introduce them to correct terminology along the way.

Don't get me wrong. I am suggesting seriously reconsidering everything. Ultimately however I don't think the changes would be so radical or numerous as to undermine anything. But it won't be painless either, which is why it's best to get everything ironed out asap. Think of the website/community right now as in a Beta period. It's best that everything be fixed in stone when things really heat up, so we can have a sturdy foundation for the future.

Something neutral and technical won't hurt either if/when the tools branch out for use in different types of productions and games. The core terminology needs to be independent so users of different variations of the tools can communicate without misunderstanding.