Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.

...

#TitleUser StoryImportanceNotes
1Localized Web UIUser 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.
2Localized NiFi docsUser 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 it its PR was not merged unfortunately, due to the massive change in NiFi 1.0.
3Localized Component docsUser 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
4User level localization  
  • For some organization it may not be ideal to change language at NiFi instance level.

...