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

Ideas for the new design #323

Open
ocean90 opened this Issue Mar 10, 2016 · 10 comments

Comments

5 participants
@ocean90
Member

ocean90 commented Mar 10, 2016

Use this issue to dump your raw ideas/mockups/sketches/…. Don't get too technical, instead, open a new issue.

Use one comment per idea and if you like somebody else's idea, give it a 👍 reaction.



Logs of the first chat: https://wordpress.slack.com/archives/glotpress/p1457985681000105
Attendees: @chantalcoolsma, @samuelsidler, @ocean90

@ocean90 ocean90 added this to the Future milestone Mar 10, 2016

@chantalcoolsma

This comment has been minimized.

Contributor

chantalcoolsma commented Mar 11, 2016

Something what is much wanted by Translation Editors, is the ability to give a reason when rejecting a string. The translator should get a notification, so he/she can correct the mistake. Below an example in the current design:

schermafbeelding 2016-03-11 om 08 58 45

@chantalcoolsma

This comment has been minimized.

Contributor

chantalcoolsma commented Mar 11, 2016

Crowdin has the option to add a comment to a translated string and optionally mark it as an issue. This could ping the Translation Editors with the permalink to the specific string and take a closer look.

schermafbeelding 2016-03-11 om 09 03 15

@isaackeyet

This comment has been minimized.

isaackeyet commented Mar 11, 2016

It would be great to have reject reasons. However, I think adding standard "reject reasons" is the way to go. I used a translation tool for validators only before, and this was a very useful feature. Sometimes you add a comment anyway, but selecting the core reason for the rejection should be sufficient for most users.

The workflow for a validator could then be:

  • Approve current string (CMD+Enter) (moves to next string)
  • Reject current string (CMD+Delete) (opens Rejection Details)
  • Select Language Style Guide (CMD+1)
  • Add comment (textarea already selected): "We don't capitalize actions in Swedish"
  • Submit (CMD+Enter) (moves to next string)

We may have to use CMD + Shift + Hotkey or similar, but the idea is the same.

Reject reasons could be:

  1. Style Guide
  2. Glossary
  3. Grammar
  4. Punctuation
  5. Branding
  6. Typos
  7. Other

A day in the life of a validator:

⌘Enter, ⌘Enter, ⌘Enter, ⌘Delete, ⌘6, "'Registrering is misspelled", ⌘Enter, ⌘Enter, ⌘Delete, ⌘4, ⌘Enter, ⌘Delete, ⌘4, ⌘Enter, ⌘Delete, ⌘4, "Please be careful about proper punctuation.", ⌘Enter, ⌘Enter, ⌘Enter, ⌘W

Here's a rough sketch of said UX:
reject-reason-sketch

@chantalcoolsma

This comment has been minimized.

Contributor

chantalcoolsma commented Mar 11, 2016

Great idea. I have another one:

I like the way Github shows actions. It would be great if you could click a string, then it collapses open and you would see something similar like this:

schermafbeelding 2016-03-11 om 10 31 40

For example if a translator translated the string and when an editor approved or rejected the string. If rejected, you could show the standard reject reason.

@isaackeyet

This comment has been minimized.

isaackeyet commented Mar 11, 2016

It would be great if you could click a string, then it collapses open and you would see something similar like this:

This would be great to have. It would require the ability to store the history of a string indefinitely. As long as this is technically feasible I think we should pursue it.

@ocean90

This comment has been minimized.

Member

ocean90 commented Mar 11, 2016

Let's not get too technical in this issue. :)

It would require the ability to store the history of a string indefinitely.

There is #209 which is about implementing a framework to attach data to a translation. Data can be status changes, comments, reject reasons or any other type of notes.

@ocean90

This comment has been minimized.

Member

ocean90 commented Jan 17, 2017

@tobifjellner

This comment has been minimized.

Contributor

tobifjellner commented Jan 17, 2017

Another thing that would be really useful is highlighting of what changed in the original when a string was marked fuzzy. Best with some kind of text background. Say red background and strikethrough for deleted characters, and green background and bold for new chars.

I tried to simulate the idea via markdown. Didn't really work. I'll do it differently.

@ocean90

This comment has been minimized.

Member

ocean90 commented Jan 17, 2017

@tobifjellner That's more of a request for a missing functionality, not directly related to design. I think #427 is related to your idea.

@ocean90 ocean90 added this to Backlog in The New Design Mar 5, 2017

@Presskopp

This comment has been minimized.

Presskopp commented Apr 25, 2018

We did another mockup, in connection to give feedback when rejecting, please see: #324

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment