org.hl7.fhir.core
org.hl7.fhir.core copied to clipboard
hapifhir
Option locale without effect
just english (en). Language is set to german by default through windows command, but i need the display in english for debugging purposes.
I'm assuming this is regarding the output of the validator cli @mmreith ?
@mmreith can you send me the exact steps to reproduce please?
Thank you.
@markiantorno My call was (but you could use whatever you like): java -jar validator_cli.jar -ig aws-zertifizierung\Sollprofile\PF20_all_Mussfelder -ig aws-zertifizierung\Sollprofile\PF24 -ig aws-zertifizierung\Sollprofile\PF22_24_Mussfelder -ig KBV_FHIR_AW\KBV-Basis -ig KBV_FHIR_AW\Terminologie -ig KBV_FHIR_AW\Application -ig KBV_FHIR_AW\Extensions-KOPIE -ig de.basisprofil.r4#0.9.11 -version 4.0.1 -recurse -no-extensible-binding-warnings -locale en Mustermann_Martina_5faa0942-a96c-43c7-ad25-0854829bd083_AW.xml
but i did not get an output in english. If you want to reproduce that, you might have to set -locale de, since this is an available translation,
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm having the same problem and now I find that it has already been reported here.
F7 confirms that the parameter gets parsed correctly and that CliContext.locale (which defaults to English anyway) gets set accordingly. Couldn't find where the translation occurs because it doesn't happen when I run the jar under the IntelliJ debugger (had -locale nl in order to make it differ from both the system locale and defaultish locales like C or en).
One problem definitely lies in CliContext.setLocale(Locale), which receives a valid Locale object but stores only its localised display language name. In CliContext.getLocale() there is a half-hearted attempt at getting a Locale object for this stored string, but that must fail because a localised display language name is not a valid BCP 47 language tag as expected by Locale.forLanguageTag(String).
Replacing locale.getDisplayLanguage() with locale.toLanguageTag() in CliContext.setLocale(Locale) should fix that particular problem. However, whether this solves the problem with the -locale parameter remains to be seen. I am in no position to build the validator jar, so I cannot test this.
@markiantorno: found one link in the causal chain for the '-locale' problem; could you please have a look?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
