Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parse => to_text shouldn't change the file #14

Open
dfherr opened this issue Aug 20, 2014 · 2 comments
Open

parse => to_text shouldn't change the file #14

dfherr opened this issue Aug 20, 2014 · 2 comments

Comments

@dfherr
Copy link
Collaborator

dfherr commented Aug 20, 2014

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 ?

@grosser
Copy link
Owner

grosser commented Aug 20, 2014

Sounds good to me, does not matter if you break stuff, should be easy to adept to ...

@dfherr
Copy link
Collaborator Author

dfherr commented Aug 21, 2014

okay fine. this could take a while as it's low prio refactoring, but is definitly on my todo list :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants