i18n?

[Harown]

We would love to use lforms but we need it in a different language. Atm the texts and date formats are hardcoded. @plynchnlm mentions in #34 the possibilty to provide a configuration file. Any chance that happens in the near future? Ideally, that config file would include not only texts but also the possibility to add more date formats. Unfortunately, we are not familiar with Angular - otherwise we would do it by ourselves and provide a PR. At least we could offer a PR with all translations into German. :)

[plynchnlm]

Unfortunately I don't think it is likely we could get to this until next year. You might consider forking it, editing any English text you find, and putting in German. I don't think you would need to know AngularJS to run the build process (npm run build). Alternatively, if you look at the page of SDC Implementations (https://confluence.hl7.org/display/FHIRI/SDC+Implementations) you will see some packages named FHIRPower.Tools, from a company which is based in Germany. I don't know if they have something that would meet your needs or not, but I have seen some impressive demos.

Anyway, I will keep this issue open and open internal ticket for adding some language and date format support.

[Harown]

Thank you very much. Good to read you opened an internal ticket. We might fork it temporarily as you suggest. The steps provided in the README to build the component work well.

[Harown]

Have you had time to focus on the internationalization feature or is it on your roadmap for the close future? If not we consider to implement it. Unfortunately, we have no expertise in Angular and would hire some developers/a company to implement it. It would be important for us to get this feature merged into your master so that we can get all future updates regarding FHIR, security and so on. We also could provide a German translation then. We found that guide from the official Angular website but we don't know

• how to estimate the effort in man days
• if there are special requirements regarding the lforms structure when externalizing texts and date (and time) formats

It would be great if you can give us some (rough) key data for these two questions.

Thanks in advance!

[plynchnlm]

We are working something related-- adding support for the FHIR translation extension within FHIR Questionnaire & QuestionnaireResponse. We are understaffed at the moment, so I expect that work will take at least a couple of months-- but maybe we will release support a bit at a time. Configuration for the strings and date formats would handled in a configuration file for lforms, so it would be a different set of changes, though there would be some overlap. For instance the API for setting the current language for the Questionnaire should also set the language for the lforms widget text (if the same language exists in both places). I think it makes sense to consider this task as part of the translation work, and I'd expect us to have it done (but can't promise) within 6 months. It is not 6 months of work, but we have multiple projects we are working on.

If you are only interested in German, then I think you might not need to hire anyone. Assuming you are able to build the lforms package from the source files (and I'd happy to answer questions if you run into problems) then you could search the source code for text strings you want to change, change the date format (look for nzFormat in the src files), and then rebuild.

[Harown]

Thank you very much. We already made a branch and changed some texts to German (that was already for version 29). Now we'll get some projects with internationalization requirements, i.e. a the user must be able to switch languages. For the start it will only be English and German so we are able to bridge those 6 months with our German branch and with the original lforms. We just migrated to the current version 33. Building was no problem, even on a Windows machine (the only problem was the build:version script but the workaround from #85 (comment) did the trick). It seems to render
faster than version 29 (maybe placebo effect :-D) and the popovers and the datepicker are much more beautiful. 👍

[plynchnlm]

It would be helpful to see a list of the places/strings you have changed, so that we make sure to cover at least those cases. One easy way to do that would be to submit a pull request with the German changes (if you can share those). I would decline it, but use it as a reference.

Yes, starting with version 30, there should be some performance improvement. I am glad to hear you like the changes.

[annabel-uzl]

Is there an idea on how to handle these translations? Using locize? Using translation files?
I've only worked with Locize for this but I would be happy to submit a first pull request using translation files for a part of the widget so we can see if that would be a good option to extend over other files.
I don't think we need to provide translations for all the components at the same time?

[plynchnlm]

I think we should go through the texts changed the PR above and pull them into a configuration file. Changing the configuration file would still require a rebuild, but at least they would be easy to find. We could even add support for picking a language, in the configuration file contained more than one. I will try to give that work (which does not seem difficult) some priority, but it may still take us a while, depending on what other issues come up. Until we get to that, I suggest just making a fork and editing, using the PR above as guide.