[Discussion] Refactoring i18n and l10n

[alxbl]

Feature Discussion: i18n and l10n support

Currently, languages are a simple drop-down selection which results in fully distinct findings in the finding database. This can make multi-language management difficult as there is no clear relationship between a finding and its different localizations. The end result is duplicate findings with slightly different names across multiple languages, and findings updated in a language but being forgotten in another. We're about to start doing some initial work on our fork of Serpico to implement proper i18n and l10n support. Initially, this would be rudimentary and cover our short term needs, but would set the stage for full fledged internationalization in the long term. Before getting too far ahead in this, I wanted to get the ball rolling upstream to see if this would be welcomed changes and whether there is interest in the feature.

In the long term, it would be beneficial to have all static content fully localized in a way that allows to dynamically switch a report's language, but there are issues tied to managing report-specific additions which would need to be solved beforehand.

Here's what we have in mind.

Usage

• Master findings would be tied to a new localization table in the database, which would have the default (English) localization along with any additional localization that has been submitted and approved.
• Finding instances would preserve the relationship back to the master finding (to allow for localization submission to the master DB)
• Adding a finding to a report would automatically select the locale according to the configured report language (re-using the existing language drop-down) and instantiate a new finding for the active report.
• If the localized finding does not exist, a warning would be displayed and the English fallback will be used, with an option for submitting the localized finding back to the master finding database for addition.

Backward compatibility

• Existing findings in the database will remain unaffected and distinct.

Additional UI elements

• To help with migration and management, an administrative interface that allows to group existing findings together as different locales will be implemented
• A localization interface in a two-column layout (Source -> Destination) will be added to facilitate localization on the spot

Modified UI elements

• The master finding editor would support managing localizations under an existing finding

[BuffaloWill]

@alxbl The technical points make sense and I am happy with this design; it would be welcome upstream for sure.

[frisch-raphael]

This might be of interest for you :
#455

[alxbl]

@frisch-raphael Wow, that's almost exactly what I had in mind. I'll see if I can work off of what you have already built instead. I think the only thing missing at this point would be some kind of UI to make it easy to migrate existing findings to the localized version. I'll try to find time to work on it in the coming days.