Hello everyone,
Existing concept_view table has below concept details:
concept_id
concept_full_name
concept_short_name
concept_class_name
concept_datatype_name
description
We found that “concept_full_name” column is giving NULL values when we have Fully Specified Name given in locales other than English.
Is this expected behaviour? Or should it contain all the values irrespective of locale?
@angshuonline@praveenad@buvaneswariarun@mksrom@mksd@binduak
@samuel34 did you create that SQL query, how did you migrate it from somewhere else? See here.
The PR is here actually. @vineela you may want to dive into the PR and ticket to see if the conversations are giving clues as to where the original SQL query comes from and why it was designed the way it is.
Thanks @mksd, The ticket from the above PR is not very specific to concept_view creation. That ticket is for the whole liquibase.xml.
But from the create sql here, I could see that we are choosing the concept full name only in english locale. May be at the time of creation of concept_view, we might have considered only English.
Going forward do we think we should give support for all the locales? @mksd@mksrom@angshuonline@praveenad@buvaneswariarun
@Vineela, I have noticed too in many places the preferred locale is English. @buvaneswariarun & I are working on the Internationalisation of some of Bahmni modules (Registration and Clinical Dashboard). we are trying to address some of the locale concerns here but updating such findings like yours is not in our scope. In the future we can include localisation as one of the acceptance criteria for all new developments.
Yes of course, it is a design flaw of Bahmni to be ‘en’ centric. Improving its i18n is part of the tech debt that needs to be addressed on an ongoing basis.
The intent of the “view”, )its not a table) is towards ease of reporting. I am surprised that it found its usage in Bahmni-core. I think it ought to be in Bahmni-reports. I think @mksrom found it to be misplaced in another endTB specific migration and reliance of it in Bahmni-core. We should change that to move the migrations to Bahmni-reports only and also refactor some of the dependencies in bahmni-core, which i checked and think can be easily overcome with alternate means.