There are some issues I am facing with implementation. First OrgUnit is no more localized as was earlier. Maybe this is good for some implementation, but not to all, like we have multi language requirement here in Tajikistan. New implementation of categorycombos does not have translation functionality.
Another issue is use of validation rules for data entry using regex. Existing regex for shortname does not validate cyrillyc letters (unicode), latin chars (ANSI) are ok.
Looking at these two issues I suggest to create some sort of common service wich accesses key/value pairs and that is used to determine behaviour of the system or module. For above examples we could use global property of translate OrgUnit or not. Or we could easily adjust regex to match our
needs.
I developed the blueprint in part from things that came up in Tajikistan while I was there, as well as from other places where the need for flexible in-field validation is required.
It is a good point regarding the Cyrillic characters, where validation would likely need to happen on the server side, since Javascript is not well suited to validation of Unicode.
There are some issues I am facing with implementation. First OrgUnit is no more localized as was earlier. Maybe this is good for some implementation, but not to all, like we have multi language requirement here in Tajikistan. New implementation of categorycombos does not have translation functionality.
Another issue is use of validation rules for data entry using regex. Existing regex for shortname does not validate cyrillyc letters (unicode), latin chars (ANSI) are ok.
Looking at these two issues I suggest to create some sort of common service wich accesses key/value pairs and that is used to determine behaviour of the system or module. For above examples we could use global property of translate OrgUnit or not. Or we could easily adjust regex to match our needs.
Thanks for clarification. I understand importance of validation. We have trouble with duplicates, etc. We have few OrgUnits, and have mach more Data Elements say compared to India, so cases vary. Looking at all these I am thinking it would be better to have expandable System Settings, which would allow us to customize regex for each implementation providing default. This would allow to say translate or do not translate OrgUnits, validate or do not validate shortnames, etc instead of removing existing feature.
I developed the blueprint in part from things that came up in Tajikistan while I was there, as well as from other places where the need for flexible in-field validation is required.
It is a good point regarding the Cyrillic characters, where validation would likely need to happen on the server side, since Javascript is not well suited to validation of Unicode.
There are some issues I am facing with implementation. First OrgUnit is no more localized as was earlier. Maybe this is good for some implementation, but not to all, like we have multi language requirement here in Tajikistan. New implementation of categorycombos does not have translation functionality.
Another issue is use of validation rules for data entry using regex. Existing regex for shortname does not validate cyrillyc letters (unicode), latin chars (ANSI) are ok.
Looking at these two issues I suggest to create some sort of common service wich accesses key/value pairs and that is used to determine behaviour of the system or module. For above examples we could use global property of translate OrgUnit or not. Or we could easily adjust regex to match our
needs.
I think some of these internationalization issues are bound up with the current problem of using the name as canonical identifier. I think as we move towards establishing a more stable separate id for identifiable elements it will make internationalization more straightforward.
regarding regex, yes this has been discussed before. Regex with unicode characters is pretty ugly though possible. But I agree that where we use them (or do any other type of string validation), we need to have a mechanism to select from the appropriate set of regexes for a specific locale. Some kind of internationalization audit is required. Just a thought - can we use our current internationalization mechanism for this? ie. regexes, like other locale/labguage specific strings, should not be hard coded but always referred to via our existing internationalization abstraction. This way we might be able to manage these strings in the same way as we manage any other, providing “translations” where appropriate.
Thanks for clarification. I understand importance of validation. We have trouble with duplicates, etc. We have few OrgUnits, and have mach more Data Elements say compared to India, so cases vary. Looking at all these I am thinking it would be better to have expandable System Settings, which would allow us to customize regex for each implementation providing default. This would allow to say translate or do not translate OrgUnits, validate or do not validate shortnames, etc instead of removing existing feature.
I developed the blueprint in part from things that came up in Tajikistan while I was there, as well as from other places where the need for flexible in-field validation is required.
It is a good point regarding the Cyrillic characters, where validation would likely need to happen on the server side, since Javascript is not well suited to validation of Unicode.
There are some issues I am facing with implementation. First OrgUnit is no more localized as was earlier. Maybe this is good for some implementation, but not to all, like we have multi language requirement here in Tajikistan. New implementation of categorycombos does not have translation functionality.
Another issue is use of validation rules for data entry using regex. Existing regex for shortname does not validate cyrillyc letters (unicode), latin chars (ANSI) are ok.
Looking at these two issues I suggest to create some sort of common service wich accesses key/value pairs and that is used to determine behaviour of the system or module. For above examples we could use global property of translate OrgUnit or not. Or we could easily adjust regex to match our needs.