Improve text. All text.
This MR is the home of my efforts to walk through every piece of text in GitLab and make sure it's up to our (or I guess, my) standards, in terms of English correctness, consistency across the board (e.g., "Create Merge Request" vs "Make a merge request" vs "New merge request") and general correctness and descriptiveness.
-
public/ -
Improve text on error pages.
-
-
lib/ -
Improve Git access error messages. -
Improve description of branch protection levels. -
Improve OAuth signup error message. -
...
-
-
config/ -
User facing strings -
Improve OAuth application flash messages.
-
-
Comments by configuration vars
-
-
app/ -
app/workers/ -
app/models/ -
app/controllers/ -
app/services/ -
app/mailers/ -
app/assets/ -
app/helpers/ -
app/views/
-
-
doc/
Everyone, but especially native English speakers (cc @rspeicher), feel free to share your thoughts and correct me when I make a mistake. :)
Merge request reports
Activity
@DouweM Let me know if you want to split this up between us. You can assign me a directory to go through, or something.
96 end 99 build_status_object(true) 97 100 end 98 101 99 102 def user_push_access_check(changes) 100 unless user && user_allowed? 101 return build_status_object(false, "You don't have access") 102 end 103 104 103 if changes.blank? 105 104 return build_status_object(true) 106 105 end 107 106 108 107 unless project.repository.exists? 109 return build_status_object(false, "Repository does not exist") 108 return build_status_object(false, "A repository for this project does not exist yet.") Both are correct, right? I think "yet" at the end reads more natural, and "yet" after "not" sounds a bit more (a bit too too?) formal.
It depends on the tone with which we want to speak to the user. I prefer to be more personable and less formal. Wherever GitLab is used, it's either the user's employer, or GitLab.com addressing them. In both cases the app is pretty close to the user.
I don't have a strong opinion on this specific example, but stylistic things like this are nice to get out of the way now for consistency's sake.
I think something has been written about tone in the contribution guide, but I'm on my phone and can't quickly check right now.
- Last reply by Douwe Maan
@rspeicher Thanks!
If you want to get in on this, could you perhaps start with the docs?
For the sake of setting a standard for word choice and capitalization etc, I think it's easier if I start with the actual app by myself at first.
Once the docs are cleaned up (feel free to move things around as well), which should keep you occupied for a while, I should be further along with establishing and writing a basic style guide and we can divide the task. I appreciate your feedback all along the way, of course. :)
@rspeicher Yep, stuff like that and uncapitalized "git" is what I will be looking out for :)
Added 1 commit:
- 4a17bee7 - Improve description of branch protection levels.
Added 1 commit:
- 8c881fd1 - Improve OAuth signup error message.
Added 1 commit:
- 17790a21 - Improve OAuth application flash messages.
Added 1 commit:
- 501e1215 - Fix 422 error page.
@rspeicher What do you think is the best way to get this merged in? I'd rather not wait until it's completely done, because that'll take a while, and 1) we may run into merge conflicts or have outdated views; and 2) users will be stuck with less-than-stellar text for longer is than necessary :)
I'd prefer to keep working in this MR and this branch though, so I'd rather not merge the actual MR commits, since that'll automatically close this MR (even if I open another MR with a different branch but the same commits, I think).
@DouweM I think the best solution would be to manually merge the branch into master via the command line as you make progress, then rebase this branch against master and force push to update the MR.
@rspeicher Manually merging will still close this MR though if the last commit in this MR is pushed to master. And rebasing will not help much if that just brings this MR to the same commit as master...
@rspeicher yeah, that's how it works. Makes sense to me for cases where automatic merge is not possible, and the merger wants to fix conflicts themselves rather than ask the MR author to do it.
It's annoying in this specific situation though.
Added 1 commit:
- 5d6af36f - Fix GitAccess.
mentioned in merge request !642 (merged)
mentioned in commit 8ad91d58
@DouweM thanks for taking the initiative. I can work on the docs if that's ok with you guys :)
@axil I haven't started on anything yet, so that's fine with me.
-
@rspeicher I was planning to do a general revamp of the docs so that's perfect timing. I'll take a look this weekend.
@axil Great, go for it!
mentioned in merge request !681 (closed)
@DouweM I really like to see text improved. Can you send a finished part of improvements so we can merge it? You know step-by-step we can get it in :)
@dzaporozhets Yes, I will send MRs when I finish specific parts.
