-
Notifications
You must be signed in to change notification settings - Fork 338
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
Localizable exceptions #135
Comments
This is what I really need. The word order of Korean is opposite to English, so it is very hard to translate the wallet to Korean. |
On the c++ side, fc::exceptions are already use name-value pairs for parameter substitution, so word order differences shouldn't be a problem. See the 'format' and 'data' in the last exception I generated:
JSON:
|
Ok, so we already have name-value parameters. What about error code or symbol? This would be more convenient than parsing error text on a GUI side. |
Code and name are the first two parameters of the exception object. Ben is currently replacing FC_ASSERT with named exceptions with proper error codes. |
... beat me to it. we sort of have a code, but it's not exactly what you want. The codes are embedded in the exception object. In the above example, code was 0 because I used FC_THROW to throw the base class. If I had thrown a specific derived exception, it would have had a meaningful code. Codes are defined here for the blockchain, they're that number around 30000+: but right now it's common for us to throw the same type of exception in two different places, using two different messages and two sets of key-value pairs. Unless we change the way we throw exceptions, the code won't be enough for translation. I'm only familiar with |
Related: #113 |
@emfrias - good point, I think we need to standardize messages and parameters for all exceptions with the same error code. Maybe add them to FC_DECLARE_DERIVED_EXCEPTION statements? |
I should have some code sometime tomorrow. My approach, discussed in #113, is to ideally have each individual place with an exception throw a different one. The result will be several exceptions with identical parameters and error messages. We may wish to collapse these to a single exception for translation purposes. I propose using a subclassing mechanism to accomplish this collapse. The localization framework should have a way to associate an error message with a particular exception type. When given an exception of derived type I believe I can write a program to use |
@theoreticalbts sounds good to me.. but I have a feeling that there might be an easier solution that doesn't involve subclassing. Also if translation is missing in some language we can just default to english. |
This issue was moved to bitshares/bitshares-core#37 |
It would be nice to have exceptions that we can translate to other languages in GUI.
In order to do this an exception may require to have some code or symbol and parameters, e.g. exception object might look like this:
{
error: "not-valid-address",
param1: "1EDJEW3508324LJDSF908342L",
eng: "Not valid address: %1",
message: "Not valid address: 1EDJEW3508324LJDSF908342L",
stack: ...
}
The text was updated successfully, but these errors were encountered: