-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Translation Enablement - Phase 1A #7247
Conversation
Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run; then say 'jenkins, test it'. |
/cc and thanks @shikhasriva |
|
|
Steven, wasn't Martin's change included that supported fallback to English? |
@DTownSMR yes - but it required a hard coded list of locales. Looking at how to avoid that. |
The test that's failing is one of our browser based unit tests. You can run this locally with |
@Bargs: Thanks for the tip. I ran the unit tests as you suggested and one of the tests is failing. It seems to be "debounce service -> cancel". I have added the error output as follows: http://dpaste.com/3PHSWRC |
* documented in TRANSLATION.md * using angular-translate * English strings in src/plugins/kibana/public/settings/sections/indices/i18n/en.json Fixes: elastic#7255 Author: Scott Russell <scott_russell@us.ibm.com> Author: Martin Hickey <martin.hickey@ie.ibm.com> Author: Steven R. Loomis <srloomis@us.ibm.com>
* Otherwise, the '$http GET' to fetch translation resources shows up as a deferred task here. * May have fixed elastic#5446
jenkins, test it |
^ 2337/2337 passed, but the server exitted with failure. |
jenkins, test it |
@rashidkpc @Bargs thanks- what's next? |
@srl295 is the code ready for review? |
|
||
For this example, we will demonstrate translation into Maltese (Language code `mt`). | ||
|
||
- Check out the `kibana` source code with `git`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should instruct the user to fork the Kibana repo rather than just checking it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
- fork, not checkout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docs updated
@srl295 I started looking at the code a bit today, I'll try to dig in more on Tuesday next week and provide some more feedback. |
I haven't given this a thorough review, but I do have one immediate concern: by translating the template strings via directives/filters during runtime rather than by a consistent process at build time, we're limiting translation support to only angular templates, and we make it much harder to develop tooling around the translation system. We don't have a plan to move away from angular at the moment, but we definitely don't plan to be on angular 1.x forever. As for tooling, I think a bare minimum for a translation system would be the ability to programmatically find missing translations in a language file, which Kibana core CI builds would outright fail on if there were any missing english translations. I'm not sure how reliable that would be when translations are applied at runtime. |
@epixa Thanks for the feedback. Please see in #6515, we aren’t tying this solution to Angular in any way. The files are just JSON files, and we show examples of non-Angular components using them. We don't have any of these in the PR for this particular phase.
@hickeyma is working on exactly that- automated tooling to compare the translation file (e.g. |
Glad to hear about not being coupled to angular! I should have reviewed the contents of the PR more thoroughly, but I really wanted to get you some initial feedback before I headed off yesterday. My concern with tooling wasn't so much about ensuring that other languages had the same translations as
It's imperative that that scenario cause an error at build time so that it wouldn't even pass CI. |
Ok. Maybe use https://www.npmjs.com/package/angular-translate-extract for
testing.
|
@epixa Thanks for the feedback. I am wondering if testing of the identifiers in the code (JS, HTML etc.) comes under the current testing of Kibana? My thinking is that adding globalization support does not alter the functionality of the product, it added the identifiers and string substitutions for each language supported. If an identifier is therefore incorrectly added, should this not be picked up by current testing as the string will not be returned? |
From a practical perspective, I don't think relying on the existing tests is going to be feasible. Getting complete test coverage on Kibana is admirable, but there are practical and technical obstacles to overcome to make that happen, so it's a long-term goal at this point. It could be years before that happens, and I'd love to get i18n support before then. Our approach for testing at this point is to continue increasing test coverage on existing code where possible and to ensure that any new functionality being added is done so in a way that is itself testable, and that would apply to something like translations as well. Stray identifiers in the UI might not technically impact functionality in the UI, but they have a negative impact on users in a much different, but no less important way. The ambiguity in a stray identifier could make a user uncomfortable using an entire feature, or worse it could make users misunderstand what the feature is suppose to do. We're talking about the possibility of adding delete data functionality in the upcoming pipeline work - for stuff like this, it is absolutely imperative that a missing identifier doesn't make that feature any less clear. But beyond all of that, I think it's important that we can test the translation system itself without running functional tests on Kibana. |
- mention 'fork' rather than 'check out' - remove TODOs
OK Kibana people… I thought I had an idea for how this could work, but now I'm not sure.
Options:
Any thoughts about the preferred approach? |
Testing should definitely be in this PR if it's going to go into master. Really I'd like to see all of 1A(X) (as well as example usage inside and outside of angular) working since building, testing, and in app usage all impact each other. It seems like we're moving in a good direction, but this feature touches so many different things its hard to predict all of the ramifications without seeing at least a POC with all the moving pieces. I don't have a good solution for creating the supported languages list yet. Optimize seems like a good place, except that the tests will also need to know which languages to test, and ideally they should run without needing the optimizer. A related question: the main GH issue says "Kibana users could "plug in" translation (language) bundles". How will this work? |
As this PR stands now, to add German they can just add the appropriate files. That's why the discovery phase mentioned here is needed.
|
I'd like to see the supported languages feature implemented through the plugin system. This would mean that installing a new language means installing a new plugin. That would give us all the tracking capabilities we need for what languages are available, it would allow us to make decisions about languages during Kibana start up, etc.
|
@epixa should (could) the built in English content also be a plugin? Is there any documentation on plugins besides the "PLEASE DON'T WRITE CUSTOM PLUGINS" message? |
@epixa Thanks for feedback on testing of stray identifiers. It makes sense that the user usability should not be broken. I agree. Potential test case could be: Loading the list of translation identifiers per localization directory and comparing with the code files (HTML and JS) for that directory for the existence of the identifiers. If identifier is not present then we have a stale or stray identifier. |
@srl295 @hickeyma I realize our feedback is kinda all over the place right now, I apologize for that. Would you be up for a video chat with @epixa and I? A lot of our feedback is driven by our thoughts on the future of Kibana's architecture, so it would be easier to hash some ideas out on a call rather than back and forth on a PR thread. We think this feature is really important so we'd like to give you guys the support you need to implement something really rock solid that'll work well into the future. I'll try to highlight a few of the high level things we'd like to discuss. Note that none of these future plans are totally concrete at the moment, which is why it's easier to talk about it rather than write about it.
|
Testing covers: - Missing locale translation files in a localization directory - Missing translation identifiers in locale translation files - Missing translations in a locale translation file The tests assume the english locale (en) in a localization directory is the reference file for checking.
… are used Check the translation identifiers in locale file against code files for that localization directory to check for stray or stale identifiers.
@srl295 Is this PR still relevant given the other work you've been doing on the i18n support? |
Can one of the admins verify this patch? |
Superseded by #7545 (which has been merged) |
How do you translate it into Chinese? Thank you |
@liangrui1988 Kibana isn't translatable yet. This issue represented an internal initial effort to support a future translation feature. |
Fixes: #7255
Author: Scott Russell scott_russell@us.ibm.com @DTownSMR
Author: Martin Hickey martin.hickey@ie.ibm.com @hickeyma
Author: Steven R. Loomis srloomis@us.ibm.com @srl295