Editor: Multiple translations in one commit

[felixhaeberle]

Challenge

Hey here, the current state is that every translation has to be comitted on their own in the editor which makes it very time-consuming and click-heavy.

Solution

Can we introduce a "Commit all changes", or even better have a list where we can choose from what should be committed? Working with the editor currently adds up to a lot of commits and if you want to keep your commit history clean this could be better.

🚘 Simple solution

• Add "Commit all" button

🏎️ Advanced solution

• Show list with changes and let people decide what they want to "stage" for an commit.
• Add "Commit all" button

🚁Most advanced solution

• Show list with changes and let people decide what they want to save.
• Revisit the concept of "staging" for an "commit"/save and change / remove it.
• Add "Save" button

What do you think about this?

[samuelstroschein]

We could change commit to save and move the commit button to the top right/somewhere else.

[ivanhofer]

What about moving the "Commit" Button into the GitFloat?

[felixhaeberle]

@NiklasBuchfink What do you think?

[NiklasBuchfink]

We have it on our roadmap. Right now, we prioritized getting users to make commits or pull requests in the first place.

I think we'll tackle that next week, look at it from a UX perspective, show our recommended flows and wording with a loom, and implement it afterwards.

[NilsJacobsen]

Was merged in #888

[stefangrotz]

I second this a lot. I lost complete pages of translations and hours of work because I worked through all translations and saved them when I was at the bottom. In the end I just commited the last change I made. At least save changes in the local cache of the browser, so that you can commit them later.

[stefangrotz]

It's possible that you may have only clicked on save once after editing all the fields. Currently, there is a save-per-field logic in place

Exactly. I translated a lot of fields and then clicked on save once at the end.

[samuelstroschein]

Hey @inlang/editor,

I think saving overall might be a web UX flaw.

The web usage expectation is auto save by default. @stefangrotz problem signals that the save every commit, or actually anything, is a UX flaw. We probably copied git workflows too hard here. I, by the way, have autosave on VSCode activated too.

Proposal

1. Auto-save changes (get rid of the "saving" concept in the editor).
2. Indicate what messages changed.
3. Have a revert changes possibility on a message.

[stefangrotz]

I, by the way, have autosave on VSCode activated too.

What do you mean with VSCode? I did not use this tool locally, but I used the web interface.

[NilsJacobsen]

I opened a issue: #1049
@stefangrotz feel free to join the discussion there.

[samuelstroschein]

@stefangrotz What do you mean with VSCode? I did not use this tool locally, but I used the web interface.

I know. I was referring to my own usage. Sorry for the confusion.

The concept of (manually) saving in the editor seems redundant. Issue #1049 will elaborate if manually saving changes in the editor will be changed.