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

How can I implement error message internalization? #355

Closed
suhdonghwi opened this issue May 26, 2019 · 2 comments
Closed

How can I implement error message internalization? #355

suhdonghwi opened this issue May 26, 2019 · 2 comments
Labels

Comments

@suhdonghwi
Copy link

Hello. I am writing a parser and I'd like to add non-English error message to the parser. But, it seems like it is not easy as I expected.

Do I have to implement custom errorBundlePretty function from scratch to completely change the whole error message? Or is it possible with custom error message system?

Also, the functions like Text.Megaparsec.Lexer.decimal, its digit is labeled as "digit" and I cannot change it unless I re-implement my own version of the function. This is another hardship.

@mrkkrp
Copy link
Owner

mrkkrp commented May 26, 2019

Yes indeed, it is hard. The library is not written with this sort of thing in mind. If we remember old parsec there was something for internationalization but only in the part that prints error messages and it made quite ridiculous assumptions about grammar of non-English languages, so it's never been practically useful, imo. This is why, I dropped any attempts at internationalization when I started the project.

It appears that you'll indeed have to write your own version of errorBundlePretty and in addition to that your own "internationalized" functions like decimal. You'll also want to define instances of ShowErrorComponent leaving a way to control localization, I guess it's only possible by using reflection.

As you can see, internationalization is rather hard to do. Now you might ask me if we could add support for this sort of thing in the library itself. To that I'd answer that it's unlikely. The reason is that software development is often about balancing things. Here, we would be balancing additional complexity with the value the new feature would provide.

It so happens that not many users really want localization of error messages. Otherwise it would be supported by other parsing libraries in Haskell ecosystem. It may be that the users are just OK with English-only output or indeed the community is not big enough to really have the need for this sort of thing in its libraries.

I welcome any input on the issue, so I'll leave it open.

@mrkkrp
Copy link
Owner

mrkkrp commented Jul 2, 2019

This one seems to be dead, I'm going to close it now.

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

No branches or pull requests

2 participants