| Target release | Release name or number |
|---|
| Epic | |
|---|
| Document status |  |
|---|
| Document owner | Unknown User (ijokarumawak) |
|---|
| Designer | Lead designer |
|---|
| Developers | Lead developer |
|---|
| QA | Lead tester |
|---|
|
Goals
- Make NiFi framework extensible in terms of localizing language
- Users can choose a language to use in NiFi Web UI
- Users can read NiFi documentations in their local language
- Remove language barrier so that users who do not use English as their primary language can use NiFi
Background and strategic fit
NiFi provides a rich Web UI and detailed documentations that can help users to build data flows by themselves. However, there are many people in various countries wanting to use this technology but not being able to consume English contents smoothly enough. If we can provide NiFi UI and docs in their local language, then we can expand NiFi community even broader.
Assumptions
- Actual translation (localization) work need not to be finished completely at any point in NiFi releases. Thus it does not affect NiFi release cycle at all. However, NiFi framework capability to extend language is managed as a part of NiFi itself.
- We will not be able to add extension point to every component all at once, so we will do it gradually.
- Any user facing strings, such as component name, messages and descriptions should be managed externally other than being hard coded in application code.
- Once the externalize effort is incorporated to NiFi code base, subsequent code change should follow the same rule in order to maintain localization.
- Each language extension should able to be added separately as user prefer.
- If corresponding local string is not found (even if a local language pack is specified), then a string in default English language will be used.
Requirements
| # | Title | User Story | Importance | Notes |
|---|
| 1 | Localized Web UI | User can interact with NiFi UI from web browser in their local language. | Better to have | - Dustin Wang (Weiresearch Info Tech) has finished extracting user-facing strings from JS and JSP files in their branch. We need to incorporate it into master branch.
|
| 2 | Localized NiFi docs | User can read NiFi docs (e.g Admin Guide) in their local language. | Better to have | - There was a contribution for Spanish docs (NIFI-2116), but its PR was not merged unfortunately, due to the massive change in NiFi 1.0.
|
| 3 | Localized Component docs | User can read NiFi docs (e.g Processor usage or its property descriptions) in their local language. | Better to have | - Provide a mechanism to localize strings for custom components (processors, controller services, reporting tasks)
- Distinguish name and displayName
|
| 4 | User level localization | | | - For some organization it may not be ideal to change language at NiFi instance level.
|
User interaction and design
Include any mockups, diagrams or visual designs relating to these requirements.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|
| How to track the diff between the latest code and localized contents? | One possible solution is managing localization effort in different branch then merge diff periodically into master, also rebase using master. |
Not Doing
- List the features discussed which are out of scope or might be revisited in a later release.