Style considerations when exporting

[Lonami]

These are all heuristics that could be applied to the original translation files and then used as parameters when exporting the resulting file.

New lines on long strings

See #210.

This heuristic could check whether all <string> are in a single line or span accross several lines, and the maximum column to know when to split (e.g. at ≤120 characters).

Whether to escape quotes or not

See #209.

Generally quotes are intended to be escaped, as they only ever make sense to be left unescaped when there is more than one whitespace character that should be preserved. Stringlate could automatically detect quotes around multiple spaces (e.g. some people like to leave two spaces after a period like:

'Hello.  Goodbye'

and remove them when translating, only to put them back after the translation is done). User quotes would always be escaped.

New lines after \n escape

See #208.

Some projects will just use a really long line. Some will add an actual newline after the \n escape, some before.

[NotSoImportant]

Thanks for creating

[Lonami]

This matter is a lot more complex than it seems and it's hard to please everyone. Running these heuristics would hopefully support some variation accross projects while keeping the style consistent within each of them.

[NotSoImportant]

I would want to have this apply only to the strings added/updated and just keep input file in the format it was.
like this you don't need to apply a styling again at the end and cause less collateral changes

[Lonami]

Quoting myself:

The big deal here is that the translated format is lost. To support what you're suggesting, we would need to somehow merge the original translation style with the translated one, prefer to preserve the already-translated one, and then to keep the same order as the original translation, apply only new strings to the original style… Very complex!

[NotSoImportant]

The part of "keep original file and changes separately" should not be that hard, that's standard patching functionatlity and should be available e.g. as library.
Having the patching/merging mechanism (like you commented would be needed for #205) and not do any formatting change would at least not touch strings unchanged by the user.

Only prio2 would be to detect existing preferences in formatting and apply them to new/changed strings.
So this is more a kind of goldplating ;-)