R property file

[denislepage]

A couple other thoughts/details.

If we are going to keep a list of the API entry points url’s in R, we might as well maintain the list of keys in there too. Having the API provide the keys would only make sense if it also provides the list of all the table names and matching entry points, so the R code can loop through those we marked as metadata, for instance. My first instinct is to keep this logic in the R code. Having them all in the core property file separated from the code would be helpful.

Just thought of something else related too. It would be nice to plan for multilingual support. That would mainly just apply to warning and errors. Would it be much more work to have a list of constants in the property file that would keep in one place all the content to be translated? I don’t imagine it will be too much work to do all at once at the end, either, if that complicates things too much.

E.g. something like this?

ERROR_API_CONNECTION = “There was an error accessing the NatureCounts server…” WARNING_FIELDS_ADDED = “There following fields were added to your database”

[steffilazerte]

I can add the keys to the list of api links, no problem.

I'm happy to place all the messages/warnings/errors together, but official translations will automatically collect all messages into a file where the translations can be added (I think, from my tests). I've been looking into it, and it's a bit convoluted :/

Were you thinking of approaching the translation differently?

[denislepage]

I am not sure what capacity R offers for translations. We should use whatever makes the most sense.

If it turns out to be poorly supported or too complicated, we should hold off. I thought that the idea of grouping all the language resources in one place would be a useful step for whenever we’re ready.

There are a couple (perhaps useful) links about how to support internationalization:

https://colinfay.me/r-installation-administration/internationalization-and-localization.html

https://developer.r-project.org/Translations30.html

This is a low priority for now, but if there are easy steps we can take now to facilitate our life later, we should try to do that.

Denis

[pmorrill]

If the R-client starts carrying error / warning msgs, then I can just start handing back the error code (rather than message string) and the client can perform the mapping. Maybe for the moment, I will hand back both the code and the EN string, then as the client evolves we can adjust.

[steffilazerte]

@pmorrill Right now the function catches the error messages (strings), and actual errors (http errors). So we can do either. If I've set it up properly, you should be able to switch to errors and everything should be fine (I think? depends a bit on what you mean by sending the error code). However, I don't think R would be able to translate errors from the server, I think it can only translate errors/messages/warnings defined in the R package.

@denislepage Looking at the docs, I'm pretty sure we don't have to put all messages together. It looks like the functions sort through the package and create something like a dictionary file with all the messages/warnings/errors. We then go and fill it in with the appropriate translations. So I won't centralize the messages, but I will bear in mind the need for future translations.