You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 23, 2019. It is now read-only.
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).
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.
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.
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
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!
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 ;-)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
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
escapeSee #208.
Some projects will just use a really long line. Some will add an actual newline after the
\n
escape, some before.The text was updated successfully, but these errors were encountered: