Environment
Knowage CE 9.0.10
Apache Tomcat 9.0.120, Eclipse Temurin JDK 17
MariaDB 12.3.2 (metadata DB)
Browser: Chrome
Default language: it-IT (SPAGOBI.LANGUAGE_SUPPORTED.LANGUAGE.default)
Expected behaviour
The official documentation (chapter_3/localization/index.rst, How use Localization Management) explicitly lists among the user-created objects that can be translated:
Analytical Driver name shown in the Parameter Panel
and documents the mechanism:
Check the available languages under the Domains configuration in the Admin menu (see the entry with domain code LANG). The ValueCd must have the ISO code of the language (three letters).
Inside the knowage metadata database the table SBI_I18N_MESSAGES contains the labels translations.
LANGUAGE_CD: must be the ID of the language from the SBI_DOMAINS table
LABEL: is the label name to be used as placeholder, must begin with i18n
MESSAGE: contains the translated string
ORGANIZATION: the tenant name
So a driver whose label is i18nAzienda should be displayed using the MESSAGE of the matching SBI_I18N_MESSAGES row for the current locale.
Actual behaviour
The raw label is displayed, with a cosmetic capitalization applied by the UI: i18nAzienda is rendered as I18nAzienda.
Translation never happens, regardless of prefix or language code used.
Steps to reproduce
Ensure SBI_DOMAINS contains a LANG entry with a three-letter VALUE_CD (a default installation has ITA and ENG).
Rename an analytical driver label used by a document, e.g.:
UPDATE SBI_OBJ_PAR SET LABEL = 'i18nAzienda' WHERE LABEL = 'Azienda';
Insert the translations:
INSERT INTO SBI_I18N_MESSAGES (ID, LANGUAGE_CD, LABEL, MESSAGE, USER_IN, TIME_IN, ORGANIZATION)
VALUES (9301, 162, 'i18nAzienda', 'Azienda', 'admin', NOW(), 'DEFAULT_TENANT'),
(9302, 164, 'i18nAzienda', 'Company', 'admin', NOW(), 'DEFAULT_TENANT');
(162 = ITA, 164 = ENG in a default installation.)
Restart Tomcat to clear any cached message map.
Log in and open a document that uses that driver.
Result: the parameter panel shows I18nAzienda instead of Azienda / Company.
Tested with ORGANIZATION = DEFAULT_TENANT, matching SBI_OBJ_PAR and SBI_OBJECTS.
Root cause
knowage-core/src/main/java/it/eng/spagobi/analiticalmodel/document/handlers/AbstractDriverRuntime.java, tag v9.0.10, method initAttributes (line 194), line 197:
194: void initAttributes(AbstractDriver driver) {
195: id = driver.getParameterUrlName();
196: biObjectId = driver.getId();
197: // label = localize( driver.getLabel() ); <-- localization disabled
198: label = driver.getLabel();
The localize() call is commented out, and the method itself no longer exists in the class — the string localize appears only inside that comment. The backend therefore returns the raw label to the frontend.
This is consistent with the frontend: in knowage-vue, src/components/UI/KnParameterSidebar/KnParameterSidebar.vue renders the label directly in all six branches of the template:
{{ parameter.label }} {{ parameter.mandatory ? '*' : '' }}
which is correct if the backend is expected to deliver an already-localized string.
For comparison, the legacy AngularJS frontend still shipped inside knowage.war (js/src-9.0.10/angular_1.4/tools/documentexecution/documentParamenterElement/documentParamenterElementTemplate.jsp) still performs the lookup client-side:
{{i18n.getI18n(parameter.label)}}
So the capability existed and was lost somewhere between the AngularJS and the Vue parameter panel.
Note that the supporting infrastructure is entirely intact: I18NMessagesDAO still exposes exactly what the call would need —
public String getI18NMessages(Locale locale, String code) throws EMFUserError;
Impact
Analytical driver labels appear to be the only user-facing text in Knowage that cannot be translated, while the documentation states otherwise. Any multi-language installation must either pick one language for all users or duplicate documents per language.
In our case: 333 documents, 1.687 driver associations, 252 distinct labels, users who need both Italian and English.
Suggested fix
Restore the call, guarded by the documented i18n prefix so that plain labels are unaffected and no lookup is performed for them:
label = localize(driver.getLabel());
private String localize(String label) {
if (label == null || !label.startsWith("i18n")) {
return label;
}
try {
String msg = DAOFactory.getI18NMessageDAO()
.getI18NMessages(getLocale(), label);
return StringUtils.isNotEmpty(msg) ? msg : label;
} catch (Exception e) {
logger.warn("Cannot localize driver label [" + label + "]", e);
return label;
}
}
If the call was removed for performance reasons — it would run once per driver per execution — caching the message map per locale would address that while keeping the documented behaviour.
Alternatively, if the feature is intentionally discontinued, please remove the corresponding section from chapter_3/localization/index.rst, which currently documents it as supported.
Environment
Knowage CE 9.0.10
Apache Tomcat 9.0.120, Eclipse Temurin JDK 17
MariaDB 12.3.2 (metadata DB)
Browser: Chrome
Default language: it-IT (SPAGOBI.LANGUAGE_SUPPORTED.LANGUAGE.default)
Expected behaviour
The official documentation (chapter_3/localization/index.rst, How use Localization Management) explicitly lists among the user-created objects that can be translated:
Analytical Driver name shown in the Parameter Panel
and documents the mechanism:
Check the available languages under the Domains configuration in the Admin menu (see the entry with domain code LANG). The ValueCd must have the ISO code of the language (three letters).
Inside the knowage metadata database the table SBI_I18N_MESSAGES contains the labels translations.
LANGUAGE_CD: must be the ID of the language from the SBI_DOMAINS table
LABEL: is the label name to be used as placeholder, must begin with i18n
MESSAGE: contains the translated string
ORGANIZATION: the tenant name
So a driver whose label is i18nAzienda should be displayed using the MESSAGE of the matching SBI_I18N_MESSAGES row for the current locale.
Actual behaviour
The raw label is displayed, with a cosmetic capitalization applied by the UI: i18nAzienda is rendered as I18nAzienda.
Translation never happens, regardless of prefix or language code used.
Steps to reproduce
Ensure SBI_DOMAINS contains a LANG entry with a three-letter VALUE_CD (a default installation has ITA and ENG).
Rename an analytical driver label used by a document, e.g.:
UPDATE SBI_OBJ_PAR SET LABEL = 'i18nAzienda' WHERE LABEL = 'Azienda';
Insert the translations:
INSERT INTO SBI_I18N_MESSAGES (ID, LANGUAGE_CD, LABEL, MESSAGE, USER_IN, TIME_IN, ORGANIZATION)
VALUES (9301, 162, 'i18nAzienda', 'Azienda', 'admin', NOW(), 'DEFAULT_TENANT'),
(9302, 164, 'i18nAzienda', 'Company', 'admin', NOW(), 'DEFAULT_TENANT');
(162 = ITA, 164 = ENG in a default installation.)
Restart Tomcat to clear any cached message map.
Log in and open a document that uses that driver.
Result: the parameter panel shows I18nAzienda instead of Azienda / Company.
Tested with ORGANIZATION = DEFAULT_TENANT, matching SBI_OBJ_PAR and SBI_OBJECTS.
Root cause
knowage-core/src/main/java/it/eng/spagobi/analiticalmodel/document/handlers/AbstractDriverRuntime.java, tag v9.0.10, method initAttributes (line 194), line 197:
194: void initAttributes(AbstractDriver driver) {
195: id = driver.getParameterUrlName();
196: biObjectId = driver.getId();
197: // label = localize( driver.getLabel() ); <-- localization disabled
198: label = driver.getLabel();
The localize() call is commented out, and the method itself no longer exists in the class — the string localize appears only inside that comment. The backend therefore returns the raw label to the frontend.
This is consistent with the frontend: in knowage-vue, src/components/UI/KnParameterSidebar/KnParameterSidebar.vue renders the label directly in all six branches of the template:
{{ parameter.label }} {{ parameter.mandatory ? '*' : '' }}
which is correct if the backend is expected to deliver an already-localized string.
For comparison, the legacy AngularJS frontend still shipped inside knowage.war (js/src-9.0.10/angular_1.4/tools/documentexecution/documentParamenterElement/documentParamenterElementTemplate.jsp) still performs the lookup client-side:
{{i18n.getI18n(parameter.label)}}
So the capability existed and was lost somewhere between the AngularJS and the Vue parameter panel.
Note that the supporting infrastructure is entirely intact: I18NMessagesDAO still exposes exactly what the call would need —
public String getI18NMessages(Locale locale, String code) throws EMFUserError;
Impact
Analytical driver labels appear to be the only user-facing text in Knowage that cannot be translated, while the documentation states otherwise. Any multi-language installation must either pick one language for all users or duplicate documents per language.
In our case: 333 documents, 1.687 driver associations, 252 distinct labels, users who need both Italian and English.
Suggested fix
Restore the call, guarded by the documented i18n prefix so that plain labels are unaffected and no lookup is performed for them:
label = localize(driver.getLabel());
private String localize(String label) {
if (label == null || !label.startsWith("i18n")) {
return label;
}
try {
String msg = DAOFactory.getI18NMessageDAO()
.getI18NMessages(getLocale(), label);
return StringUtils.isNotEmpty(msg) ? msg : label;
} catch (Exception e) {
logger.warn("Cannot localize driver label [" + label + "]", e);
return label;
}
}
If the call was removed for performance reasons — it would run once per driver per execution — caching the message map per locale would address that while keeping the documented behaviour.
Alternatively, if the feature is intentionally discontinued, please remove the corresponding section from chapter_3/localization/index.rst, which currently documents it as supported.