Bug 421220 - Add proofreading mode (similar to the ‘Alternate Translations’ feature)
Summary: Add proofreading mode (similar to the ‘Alternate Translations’ feature)
Status: REPORTED
Alias: None
Product: lokalize
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Simon Depiets
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-09 11:48 UTC by Karl Ove Hufthammer
Modified: 2020-05-09 12:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Ove Hufthammer 2020-05-09 11:48:52 UTC
SUMMARY
I sometimes get sent updated PO files from (new) translators. They can contain new translations and/or improvements to existing translations (‘proofread strings’). Before commiting them to SVN, I need to do some QA, i.e. go through each change and accept, reject or modify it. So it would be nice to have a proofreading mode in Lokalize that can be used for this, for merging the PO files.

Basically, I have two files, the original PO file and a new PO file with (exactly or mostly) the same source strings. The feature then needs to work almost *exactly* like the existing ‘Alternate Translations’ feature. The only difference is that the colour diffs shown in the panel should show the difference between the original translation and the updated (e.g. ‘proofread’) translation (instead of between the source/English string and the ‘alternate translation’).

The new ‘proofreading files’ can be stored in a separate folder but with the same filenames, just like for the ‘Alternate Translations’ translation. But since the proofreading files are often ‘one-off’ files, it would be nice to be able to drag and drop them to the new proofreading panel. And perhaps there could be an ‘Open File’ button on the panel (since drag and drop is not very discoverable, and not accessible for people who only use the keyboard).

The feature could also be used for other purposes. For example, if you have a PO file with common/standardised translations across applications, you could use this as a ‘proofreading file’, to quickly see (and possibly change) the strings which don’t use the ‘standard’ translations. Perhaps a better name than ‘Proofreading’ should be used, but I’m not sure which (‘Alternate Translation’ is a good description, but is already taken).

Details:

1. It should work similar to the existing ‘Alternate Translations’ feature.
2. But the diff should be between the original translation and the proofread translation.
3. There should be keyboard shortcut for copying the proofread translation (overwriting the existing translation).
4. There should be keyboard shortcuts for going to the next/previous string where the original translation and the proofread translation differ.
5. And perhaps a new filter in the ‘Translation Unit’ panel for only showing strings where the two translations differ?
6. It should be possible to select/open a proofreading file by clicking ‘Open File’ on the panel or by dragging and dropping a file to the panel.
7. The ‘are the two strings equal’ comparison used in item 2, 4, 5 should ignore any differences in linebreak formatting between the two strings. (Here I’m talking about *automatic* linebreaks that Lokalize and other tools automatically add to PO files when saving/merging, not ‘\n’ or other whitespace, which *are* significant, and *should* be shown in the diff.)
8. Any translations in the proofreading file that don’t have a corresponding (source) string in the original file should simply be ignored.
Comment 1 Karl Ove Hufthammer 2020-05-09 12:05:24 UTC
Hm. It looks like most if this is already implemented *in* the ‘Alternate Translations’ feature. The ‘Alternate Translations’ panel is a bit confusing, in that it shows several different things:

1. For fuzzy strings with the previous message embedded, it shows the difference between the old source string and the new source strings.
2. For an actual alternate translations (e.g. a translation ‘English → German’ when you’re editing ‘English → French’), it only shows the alternate translation, with no diff.

For the feature in this report, it would need to also show a diff between the two translations. Obviously, a diff between a German translation and a French one doesn’t make much sense. So there’s a difference between the case that 1) the target languages are different, where no diff should be shown, and 2) they’re equal or very similar (e.g., British English and Australian English), where a diff *should* be shown.