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
The parser does not remember linebreakes of multiline msgid's and msgstr's.
well this is a rather big one I didn't really thought about changing, as I use my own methods for writing the method and not to_text. In the process of refactoring I would like to do anything that is about parsing/writing with the gem.
It does not violate the gettext rules to concatenate multiline msgid's or msgstr's, but it causes for example the header to be in one line, which is not desireable.
To keep the multiline presentation while parsing, msgstr and msgid must be represented as a list (array) internally.
I could do this the harsh way which would require a version jump and breaking any existing use of the gem, or the soft way by adding helper methods for msgid/msgstr which return the concatenated version, but keeping lists for their content.
On a plus the second way wouldn't change how the mo/po interface works and wouldn't break existing code. The drawback would be performance and messy logic.
The parser does not remember linebreakes of multiline msgid's and msgstr's.
well this is a rather big one I didn't really thought about changing, as I use my own methods for writing the method and not to_text. In the process of refactoring I would like to do anything that is about parsing/writing with the gem.
It does not violate the gettext rules to concatenate multiline msgid's or msgstr's, but it causes for example the header to be in one line, which is not desireable.
To keep the multiline presentation while parsing, msgstr and msgid must be represented as a list (array) internally.
I could do this the harsh way which would require a version jump and breaking any existing use of the gem, or the soft way by adding helper methods for msgid/msgstr which return the concatenated version, but keeping lists for their content.
On a plus the second way wouldn't change how the mo/po interface works and wouldn't break existing code. The drawback would be performance and messy logic.
What do you think @grosser ?
The text was updated successfully, but these errors were encountered: