Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Marking lines that have been edited #476

Closed
imcgames opened this issue Jul 13, 2015 · 14 comments
Closed

Marking lines that have been edited #476

imcgames opened this issue Jul 13, 2015 · 14 comments

Comments

@imcgames
Copy link
Contributor

Hi guys!

We've noticed that we are getting multiple pull requests for the same lines a lot recently which doesn't seem like an efficient way for things to go. 😱
Therefore, in order to prevent duplicate works on the same line by multiple contributors,
we thought of marking the lines that have already been worked on for others to just skip those lines and continue on with lines that have not yet been checked.

We are thinking of using an 'x' in front of the codes that have been edited already,
(so that it will be easy to notice and we can just use 'replace all' before we use the file)

ex:
ETC_20150317_000001 -> xETC_20150317_000001
ITEM_20150317_000001 -> xITEM_20150317_000001
QUEST_20150317_000001 -> xQUEST_20150317_000001

but since this means that we will also ask you to mark the lines as well when you edit one,
we'd like to know how you think about it before we go on to implement it.
So please feel free to share your thoughts with us regarding this matter. 😃
(we'd like to implement this ASAP if possible 😉 )

@Pomez
Copy link
Contributor

Pomez commented Jul 13, 2015

It's a great idea but as a result, some incorrectly edited lines may easily be overlooked. For example I edited some lines but they might not be good enough. Other contributors could have handled them better than me but they just skipped them because "those lines were edited already".

@Flevalt
Copy link
Contributor

Flevalt commented Jul 13, 2015

I've had a similar thought yesterday as well, that if it were a bit more structured, it'd go much faster.

The marks are a very nice idea.
However, simply marking the line after editing it will only mark that the line has already been edited, right?
It's not an indicator of whether that line is correctly translated, whether it still needs editing or grammar checks.
So basically the mark is more of a priority indicator than an indicator of how complete the line is.
When you see the mark, you skip those lines in favor of lines that have not been marked yet.
And this continues until all lines are marked, no matter what state they were left in from their last edit.

I think everyone can agree that the translated/edited lines all differ greatly in matters of quality.
So would it not be even more beneficial to at least use a few different marks?

Something like:

xETC_20150317_000001 = Raw English translation, but still largely incomprehensible. Needs further editing to become comprehensible.
(if you can't understand what the line is trying to say, then this is the state it is in)

yETC_20150317_000001 = Correct idiomatic English translation. Requires further grammar checks
(if you can follow what the line is saying but spelling, punctuation, sentence structure etc. are wrong, then this is the state it is in)

zETC_20150317_000001 = 100% Complete. Minor adjustments needed at most.
(if you are absolutely certain that everything is flawless, then this is the state it is in.

As a contributor, I would add one of the 3 marks depending on how confident I am that this translation or edit is correct and how close it is to completion.
You could then adjust the 3 marks of the contributors depending on how the actual state of those lines are whenever you accept a commit.

But since 3 marks are more complicated than 1 and since a lot of lines have already been edited without having been marked, it would be a good idea to add a placeholder mark to all those lines that have already been edited until now, so that we contributors can at least skip those completely for now while you from imcgames don't have the effort of looking through all those chunks of edited lines just to decide whether it's x, y or z, because that might be a bit much extra work when the idea is to make things simpler.

TL;DR:
Add a placeholder mark, like: "oETC_20150317_000001", to all lines that have been edited already.
We can then skip those for now.

And from now onwards every line would receive either x, y or z in front of it's code depending on the progress for that line, so that in the future we have it easier to identify which state every line is in.
Once all of the now unedited lines have been completed, we could then start polishing the lines that have the placeholder marks and exchange the placeholder marks for marks that indicate their actual state.

TL;DR+in English:
Add "o" in front of every line that has been edited until now.
Add "x", "y" or "z" in front of every line that will be edited from today onward.
Once all lines only have either the "z" mark (which stands for completion) or the placeholder mark "o" left, we can start completing the lines marked with "o".

@emailboxu
Copy link
Contributor

@Flevalt Too complicated and most people will automatically just jump to the last stage because they assume their translation/interpretation is the best one.

@imcgames I think it's a good idea, but if you do this I think you'll need to merge Pull Requests after a few days so other people can look over the edits of the Requester. That way it only has to be merged once, and we can be more sure that it's accurate.

Small inaccuracies won't matter too much, though, because when the OTC is released all the testers will be able to edit from directly in the game and should cover the more major errors.

@megaoka
Copy link
Contributor

megaoka commented Jul 13, 2015

I like the marking idea, but I agree that lines will need multiple passes/proofs. While crowdsourcing the translation project is a fun idea, and I am enjoying myself, I have a hard time seeing it getting more organized without someone actually managing the project.

I like the idea @emailboxu had where requests are approved after 24h-48h so peers can go over the changes.

add'l - Honestly, having access to the OTC would also help significantly.

@Chaosbelow
Copy link
Contributor

Agree with both emailboxu and megaoka. One of the issues is that we could have several people editing the same 100 lines and they could have wasted their time. This has already happened on several occasions. Having a 24hr - 48hr period would help but we also need a better way of making sure the section of lines you are translating isn't also being done at the same time. Then you would have just wasted your time. This is partly the issue with the ToS Base translations coming in. We need a better way to not only mark translations that are done properly but also a way of letting everyone know the current lines being edited. Unfortunately it seems GitHub has no way of telling everyone which lines are being worked on.

@Sourpusss
Copy link
Contributor

This sounds like a good idea, but we need something to mark "completed" lines. There are plenty of lines that are currently fine (either previously translated, or were initially fine). However, it shouldn't be left up to everyone to confirm a line is "finalized."

I don't know if there is a way we can get a designated someone to make completed lines marked with an "o" or something, but if it's possible, it would be incredibly helpful. Otherwise, we could go through and just add it to correct lines.

@imcgames
Copy link
Contributor Author

I guess @Flevalt 's idea of having different marks is nice too but in reality, it will be too complicated to keep up like @emailboxu says so let's just use single mark for now. Let's use 'x' like the examples in the post?
And taking your suggestions, we will try to take 24hr periods before merging the pull requests we receive.

As for making others know which lines are currently being worked on, I don't think there is way for Github to tell that so if you have ideas, you can share it with us.
And for marking lines, let's give a shot at having it done freely by everyone (we trust ya 😉 )

@Flevalt
Copy link
Contributor

Flevalt commented Jul 14, 2015

Sounds good enough.

@ensata
Copy link
Contributor

ensata commented Jul 15, 2015

Writing an x directly in the file is a little crude, don't you think? Say what you will, but it still sounds like an invitation for file import errors.

Personally, I just made my own progress chart to the side and ticked off boxes, and it's not hard to expand it for more users and track all the passes. I even left it online. That only works if someone's managing it, or if everyone is doing it correctly, though. Working in blocks will also make it easier to follow.

@Sourpusss
Copy link
Contributor

Well, as IMC said, they can easily just use replace all before finalizing.

Also, in my previous reply I was more wondering as to how we should handle "correct" lines. Like, lines that don't need anymore editing. I guess just mark them with an "x" as well?

@imcgames
Copy link
Contributor Author

@Sourpusss yup, seems like "x" will do 😄

@toslover
Copy link

I working on translating en into another language.
I saved tsv files with atom,and atom deleted the invisibles space automatically.
Is the invisibles space used for fit the actual game UI's?
Is there any way to avoid deleting the invisibles space automatically?

@ttgmichael
Copy link
Contributor

@toslover, try notepad++? I don't use atom, but would suggest you to check the options to see why it would auto-delete tabs or whitespaces.

@toslover
Copy link

@ttgmichael,thx a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants