Updating changelogs / content separation / Crowdin handling

[moving-bits]

Today I removed a temporary entry from one of our changelog files. CrowdIn therefore invalidated the whole section of strings, so our translators had to reapply the translations for the remaining entries of that block. And although those translations are in CrowdIn's memory, they still need to be selected and approved manually. Quite a nuisance, IMHO.

Is there a way to avoid such retranslations?

Would keeping each string separated from the others by an empty line solve this problem?
Eg: A changelog could then look like this:

### category A

- string 1

- string 2

- string 3

### category B

- string 4

- string 5

Or is content separation in CrowdIn bound to headings?

(We would need adapting c:geo's display of changelogs to remove the superfluous line endings before formatting the text via Markdown, but that's easy to achieve.)

[Lineflyer]

Is there a way to avoid such retranslations?

Would keeping each string separated from the others by an empty line solve this problem?

AFAIK it works quite similar to the git change detection: Adjacent lines are triggered by a change in a line (to phrase it simple).

IMHO its not worth the effort to work around this.
In normal cases we should just append new changes at the end of a section. Doing so and the empty line below each section does the job.

Your described special case is IMHO rare and should just be avoided.

[eddiemuc]

In a MD list, crowdin treads each list item as a separate item. My assumption: if you delete an item further up in such a list, then crowdin probably thinks that you changed the item to the text of the next item in the list and so on, and that you deleted the last item. This would explain your observed behavior.

E.g. when you have:

### Colors
- blue
- green
-yellow 
- red

And you delete green:

### Colors
- blue
- yellow
- red

Then crowdin might think that you changed "green" to "yellow", "yellow" to "red" and deleted the last entry "red" of the before-list

[eddiemuc]

Crowding works key-based. Probably they internally assign keys to each list entry based on the position of the item in the list. This would explain the observed behavior.

The only idea I currently have to avoid this would be to assign keys to entries in the changelog as well (would then no longer be a markup file). E.g.

Color1=blue
Color2=green
Color3=yellow
Color4=red

And when you want to delete the second line you get:

Color1=blue
Color3=yellow
Color4=red

[eddiemuc]

As an alternative you may use mass import with auto -approval based on the current translation files in our GitHub after something like this happened. Then you would spare yourself and the translators the manual reapplying. And sinxmce translations in our GitHub exports are always approved you wouldn't falsely put wrong translations into crowdin.

I described how this works in our wiki here: https://github.com/cgeo/cgeo/wiki/Translation-%28L18N%29 (at the very bottom of the page under subsection "restore MD files")

[moving-bits]

Thanks for the insights. I guess as removing a string from changelog is a pretty rare case I prefer to stay with manual resolving then.
Only thing with that is, that we also cannot change the order of changelog items easily (which would be nice sometimes for grouping related items) - but this would require manual resolving as well with above's solutions, so maybe just stay away from reordering items ;-)