New Guidelines - Suggestions

[imcgames]

Hey guys!

It seems like since the Forums opened, we are seeing more Contributors than before. 👍 👍 👍
And... as @ensata pointed out in #536 and #458 , we need to set some guidelines to be followed.
So if you have suggestions for the guidelines, please do share it through the comments below.
Once the guidelines are somewhat complete, we will add it to Github main page and the wiki.

So far,

1. Use the latest files when editing.
2. Edit lines in groups. Chunks of 50 or 100 lines per request.
   (Do not edit more than 300 lines in a file in a single commit/pull request)
3. Write the lines you reviewed in the commit summary.
4. Mark x in front of the line codes that you edit or reviewed.

[Kxizen]

What about marking x onto lines that doesn't need to be edited?

[ttgmichael]

I think Rule 4 should be: mark x's only on the lines you editted.

If it's both edit and review, then the rule might confuse editors that come across lines that are deceptively accurate (yet still machine translated), and mark them with an x and move on; some editors who don't know Korean might mark x's just because they read the lines (as part because "reviewing" is an ambiguous verb).

The only case where the current rule 4 would be good is when the editor truly feels that the line cannot be changed too much anymore, this can happen either because someone already editted them (and forgot to mark their x's) or because the lines are names.

[imcgames]

Then what about more details to the marks?
x -> edited
o -> reviewed (good to go, no need to edit anymore)
ix -> edited by IMC Games (edited in ways to fit the actual UI in game)

[ttgmichael]

I like that suggestion. This would mean that any lines that people forget to "x" gets another pass by someone else who will then mark an "o" instead. I'm also fine with having "ix", if that's ok with you xD.

Of course, the merging of files with lots of "o's" will definitely pass 300 lines xD.

Now the only other thing is what happens when someone wants to edit a line with an "x". I notice some pulls that do that. The difficulty with this because:

1. There will be lines translated by someone which might be wrong (because they are just using Korean dictionaries and don't know the language). (Oh and I'm assuming all new commits will NOT be machine translated)
2. There will be lines translated that are right (hooray!), which means merely word structure will be changed (changes to these lines just complicates the process I think)

My opinion is that "x" lines should still be proofreadable, but can only be changed if the new line will have a significant difference in meaning compared to the line it is replacing.

[ttgmichael]

I also noticed that no one has been using labels. Should we start labeling lines that we want people to focus more on?

[ensata]

So far, I've just been ignoring the x marks, because it doesn't fit into my translation process and there wasn't enough verifiability behind it. Also, the programming side of me keeps shuddering at it.

Adding extra details to the marks might work, but only if people actually follow it and know what it means... which I somehow doubt will be maintained. If nothing else, at the moment I only trust the marks that imc puts in, since they're approving the pulls.

[ttgmichael]

Ok then, since 'x' marked lines will still be reviewed by those who wish to really check whether the lines are accurate or not, we should define the markings as such:

'x' means the line is NOT machine translated. Thus adding an x means the editor either used their knowledge in Korean or a dictionary to find the best meaning that they could from the Korean text. They shouldn't sway too much from a really good translation.
'o' means reviewed as ok (machine or non-machine translated). Means that an editor went through the line and thinks the line was ok.
'ix' means IMC translated.

This would mean we need a way to figure out whether a line is machine translated or not, which I think would be easy if we just copy the korean scripts to Google and see what comes up.

Opinions? ^^

And also, what should we do with names that aren't in the wiki (if there are any)?

[Kxizen]

You leave those things to other people that can deal with that situation. But the whole guide thing is fine by me. Please tell those guys who can't understand korean to not try and translate. You often get very bad translations so it's not even worth trying.. just proof read like i do.

[ttgmichael]

Well for that to happen, we need to know which lines can be proofread and which lines can't be. Otherwise, you are prone to proofreading lines that seems properly translated, but aren't actually. Marking an 'x' for a line at least tells us that someone tried to change it to intelligible English. Regardless of how inaccurate it may be, some of it ought to be better than machine translation.

[ensata]

Yup, and that's why I'm ignoring it, for the time being. The source of the problem is that we don't know the current status of the translation, and everyone is contributing differently. If you look at the previous issue ( #476 ) you'll see similar things brought up.

I'm using my own workflow for the lines I look at, but it's too strict and I don't expect anyone to follow it. Everyone else is doing their own thing, too, and the lowest common denominator at the moment is to allow only imc to add the x, and to make it mean "finalised. do not edit unless it's serious."

(By the by, I've been trying to determine the current state for a while now, and... yeah. There's a reason why I've been saying certain things...)

[mtnielsen]

So far @imcgames has corrected any funky translations (that literally made no sense) I've pointed out, so if you find lines that are completely broken and make no sense at all, leave them be, but point them out for those who can read Korean. Or try and make sense of them based on what's being discussed in the lines around them.

[ensata]

Since I wrote those rules in an annoyed, tired rush that time, I revisited it this morning to make the language more clear. This is really basic stuff for a collaborative project, y'know...

1. Always write a summary.
   Write down the section you reviewed in the commit summary.
   Explain the type of edit performed.
   Definitely explain your edit if you're doing a mass search and replace.
2. Edit lines in groups.
   Limit your range as much as possible to avoid potential merge conflicts.
   For example, edit a chunk of 100 lines, from 1-100, or 101-200, etc.
3. Do not edit more than ~300 lines in a file in a single commit/pull request.
   GitHub will not display a diff inside the browser if it exceeds 100kb, which is typically ~300 lines.

[ttgmichael]

@imcgames, we should put what @ensata wrote on the top of the readme and also this: #608 for those who don't want to edit the lines but want to report on what should be editted. ^^

I expect a frenzy of pull requests once the CBT is going so I hope these guidelines (that people will hopefully read) will help keep things organized.

[ensata]

Also, if you didn't see me mention it in the other issue, the x marks need to be totally removed if you want to jump the queue and use the git files directly in the game. Even if you don't remove them, there are going to be several imminent merge conflicts occurring on the first day of the CBT, when we try to submit things.

If that's not dealt with, you're going to run into a ton of NOTFOUND errors, it'll be a lot more tedious for everyone to submit changes, and we basically need to rely on imc giving the game daily patches, which is completely ridiculous. And that's probably only the start of it.

Like I said before, the programming side of me shuddered like crazy at the idea in the first place.

[ttgmichael]

Yep I read your instructions on symbolic linking the game's language folder with the github files during CBT. Isn't this linking process still dependent on the main repository being bug free? If anyone accidentally pushes changes with a misplaced mark/tag, aren't we are all going to receive the mistake?

It is obvious that the markings (x,o,ix) shouldn't be used when editting lines during the CBT, as you would be personally creating a bug to your game just by adding an x to it on the front!. I program too, so I understand what you are stressing xD. The marking idea was good when we didn't know we had a CBT coming. For what we are doing, it isn't feasible to do that. ^^;

That being said, should we still try and find a way to inform people that a line has already been editted? (otherwise, we will still run into merge conflicts with too many people constantly PRing their own version of one line).

Instead of marking the x on the front, what about the back (after the text)? (at least for lines related to quests/ item descriptions/ dialogs/ other descriptions if we want to still have a "pretty" UI to look at.)

[ensata]

It's not just merge conflicts, but code churn's a problem, too. Well, it's not code, but... y'know what I mean. Stuff constantly being rephrased and having a hundred writing styles.

In any case, I simply can't think of a viable way of marking things directly in the translation file without interfering with several processes. The way it is now, it's breaking all the dictionary names, (which broke imc's own guidelines in the Wiki, mind you) but putting it somewhere else leaves behind other issues.

Even if the lines are identical, I can't use the basic compare functions to check for parity, since it will always contain an extra letter. If someone goes around and adds the x or remove it for someone else, it interferes with tracking code churn, and complicates using git blame for tracking problematic edits. (With it, I actually know of at least one contributor who probably did not deserve their 3 keys, but I didn't complain.) I don't know if anyone's been doing that stuff besides me, but that's another conversation.

To add on top of that, all you have to do is look at today's pull requests and see that some people have blatantly ignored it, or thought that it was a bug. Even for me, I had my own reasons for ignoring it. (lines 1-1300 of quest.tsv were mostly machine translated, so I couldn't trust anyone doing an 'edit' type pass).

The two viable ways I do have doesn't work. I made my own progress sheet, but that's a personal sheet, not an official one. The second option is to add another column to the files rather than adding an x, but you still run into the problem of needing to clean the files for shipping and also outright reprogramming the text hooks, which obviously isn't possible.

[ensata]

Now that I think about it, there's actually another rule that's required, but I've mostly done it privately because no one's really organising it.

4 - Any new important Keywords, or changes to Keywords, must be immediately reported and explained for addition to the translation glossary.

Obviously, this is specific to managing a translation project, and the only reference files that exist right now is... the aging wiki, and my own private one that I shared right at the start.