Hi there,
After succesfull integration of custom localization tool, I began testing how it works. And really, it worked like a charmed, and showed good performance, and I was really happy. But as soon as I missed field for new db name, when filled in form at 2nd step of advanced installation, I was unpleasantly surprised. Regardless, wizard was running in Italian, instead of error message "Base dati di nuova nome è richiesta" I saw "New database name is required" still in English. Cause, I simply forgot about localization of error messages. So, I decided to fix it as soon as possible.
First, that you should know about, that the nature of error messages quite differs from normal messages. The first difference, is that any error message, in comparison with normal GUI message, won't be shown with 100% of probability. It can be shown, or it can't be shown, it depends. We can say that they are forming dynamicaly. But our localization tool can handle only static messages which are kept inside of messages properties files.So, as conclusion of that, we should have to teach our localization tool to handle such messages.
So, how did I accomplish that? First, I decided that all error messages should be inside properties files, otherwise, the problem seems to be unsolveable. And as next step, I defined entire set of error messages, which ever can be displayed to user. Then, I completely localized them (it took most of my time). Jumping ahead, I should say that some error messages can be formed from dynamical parts, and it makes additional inconveniences. For representation of such messages I used compound messages. More about them you can read here.
So, after all messages were prepared, I should have find the way, how to point out localization tool, which translation of error message to use. Decision was really simple and graceful at the same time - in all places in code, where forming errors, I used error messages keys. For example, when user didn't fill new db name field, instead of "New database name is required" I put "install.error.dbNewName". Thereby, localization tool will accept such key and load corresponding translation of message fo this key. For handling compound error messages I'm also putting all dynamical part of message with their code together. For this I had to use map for keeping error messages. For this map I used the key of messages as entry's key, and an array of objects as entry's value. As result, in templates handling of error messages proceeds as follows:
So, described above feature really works, and results of its work is shown below:
As you can see, now for italian locale we can see correct translation of message about occured error.
This as all for today, you can leave your comment if you have some questions or suggestions.
With best wishes, Taras Chorny!
After succesfull integration of custom localization tool, I began testing how it works. And really, it worked like a charmed, and showed good performance, and I was really happy. But as soon as I missed field for new db name, when filled in form at 2nd step of advanced installation, I was unpleasantly surprised. Regardless, wizard was running in Italian, instead of error message "Base dati di nuova nome è richiesta" I saw "New database name is required" still in English. Cause, I simply forgot about localization of error messages. So, I decided to fix it as soon as possible.
First, that you should know about, that the nature of error messages quite differs from normal messages. The first difference, is that any error message, in comparison with normal GUI message, won't be shown with 100% of probability. It can be shown, or it can't be shown, it depends. We can say that they are forming dynamicaly. But our localization tool can handle only static messages which are kept inside of messages properties files.So, as conclusion of that, we should have to teach our localization tool to handle such messages.
So, how did I accomplish that? First, I decided that all error messages should be inside properties files, otherwise, the problem seems to be unsolveable. And as next step, I defined entire set of error messages, which ever can be displayed to user. Then, I completely localized them (it took most of my time). Jumping ahead, I should say that some error messages can be formed from dynamical parts, and it makes additional inconveniences. For representation of such messages I used compound messages. More about them you can read here.
So, after all messages were prepared, I should have find the way, how to point out localization tool, which translation of error message to use. Decision was really simple and graceful at the same time - in all places in code, where forming errors, I used error messages keys. For example, when user didn't fill new db name field, instead of "New database name is required" I put "install.error.dbNewName". Thereby, localization tool will accept such key and load corresponding translation of message fo this key. For handling compound error messages I'm also putting all dynamical part of message with their code together. For this I had to use map for keeping error messages. For this map I used the key of messages as entry's key, and an array of objects as entry's value. As result, in templates handling of error messages proceeds as follows:
#foreach ($error in $errors.entrySet())where $errors - the map, mentioned above, $l10n - our custom localization tool.
#if (!$error.getValue())
<li>$l10n.get($error.getKey())</li>
#else
<li>$l10n.get($error.getKey()).insert($error.getValue())</li>
#end
#end
So, described above feature really works, and results of its work is shown below:
As you can see, now for italian locale we can see correct translation of message about occured error.
This as all for today, you can leave your comment if you have some questions or suggestions.
With best wishes, Taras Chorny!
Комментариев нет:
Отправить комментарий