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

Error message and trace translations #389

Open
vivshankar opened this issue Aug 31, 2020 · 3 comments
Open

Error message and trace translations #389

vivshankar opened this issue Aug 31, 2020 · 3 comments
Assignees

Comments

@vivshankar
Copy link

Feature request checklist

  • [ x ] There are no issues that match the desired change
  • [ x ] The change is large enough it can't be addressed with a simple Pull Request

Change
I am using CEL as a rule compute engine within my product. I have a need to be able to provide translated error messages to users and am wondering if there is any way for this to be accomplished in CEL. I am happy to inject the translation files in my code, if a mechanism exists.

Happy to submit a pull request if some pointers can be given.

Example
Undeclared reference to 'test' (in container '')

Ideally, I would like to be able to translate messages of this sort.

Alternatives considered
N/A

@TristonianJones
Copy link
Collaborator

Hi @vivshankar, if you'd like to contribute here, I can offer you some advice for the parser and checker errors in a manner that permits the use of alternative language for the error message information. Would that work for your needs?

The runtime errors are in need of love and #25 and #189 are the specific changes that need to improve runtime stack traces and error messaging.

@vivshankar
Copy link
Author

@TristonianJones Happy to take a shot at this.

@TristonianJones
Copy link
Collaborator

@vivshankar Thanks for being patient on this. I spent a little time thinking about this the other day and both the parser/errors.go and the checker\errors.go introduce an abstraction layer between the parser / checker and the common.Errors object. These minor abstractions introduce standard error messages and formats for each component.

My recommendation is as follows:

  1. Introduce a Localizer interface in the common/localizer (new) package.
type Localizer interface {
  Localize(int msgID, args ...interface{})
}
  1. Establish constants for the existing English messages in common/localizer/codes.go and a mapping from the message id to a struct containing the localized message and the number of expected arguments to the message for the sake of linting. This first mapping for English can be in common/localizer/en_us.go
  2. Create functional options for configuring the localizer for the parser and checker which adjust the localizer used when creating the parserErrors and checkerErrors objects.

This will probably take a bit of time to do, but the above is the rough idea. Please feel free to ask questions as you work through the code.

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