Add config file option to set prefered language

[zed-g]

Since #96 it is possible to specify a language via the command line argument -L/--language, this works quite well. Now I would like to always use a specific language, differing from the LANG set as an environment variable.

I played around with the config file and had a look at the code but it seems to not be supported as a config file option. Would it be possible to add this? I'm imagening something like an additional section in the config file:

[language]
language = "en"

And of course: Thank's a lot for tealdeer, it really is charmingly fast and straightforward to use!

[niklasmohrin]

I am not sure about adding another section just for this, but the general idea of having a setting seems logical :)

An implementation will have to make sure to still adhere to the client spec from upstream (where the behavior for $LANG and all that is specified), but it shouldn't be too bad

[zed-g]

I'm really not experienced with Rust, but after looking at the code I think this could be implemented by extending dbrgn/tealdeer/src/main.rs#L471 with another map_or_else which looks up an optional language configuration? And the correct order of precedence should be command line option - config option - env option?

I am not sure about adding another section just for this, but the general idea of having a setting seems logical :)

Should this go under [display] then (since it's not possible to "end" a section and have it followed with a top level setting AFAIK)?

[niklasmohrin]

From a developer perspective, I would see that option in cache, because it has something to do with page lookup in the cache, from a user perspective I am not sure. Precedence makes sense like you proposed

[9mdv]

Being able to specify a language would be nice, at least when updating:

tldr --update en

So we would only need to fetch 15 MB (for english) instead of all pages which is over 50 MB, saving disk space as well as bandwidth for those with metered connections.

[niklasmohrin]

@g11v8a This sounds like it would be better fit as a separate issue. Can you open a new one instead?

[niklasmohrin]

After thinking about #335, I think it would make even more sense if the config option wouldn't be "language", but rather "languages", since users might want to always query for multiple languages. This could then use a TOML list instead of just a string. Finally, we could (in a separate PR then) think about allowing both a string or a list in the "language" or "languages" option (or have both?).

A natural question following from that is: Should the CLI option also accept multiple languages? I think we could potentially allow for multiple occurrences of --language, but this too would be content for a separate issue / PR.

[noraj]

An implementation will have to make sure to still adhere to the client spec from upstream (where the behavior for $LANG and all that is specified), but it shouldn't be too bad

Upstream official client have different config methods and some of them have none (https://github.com/orgs/tldr-pages/discussions/10796).

Also, to complete zed-g idea, it would also be nice to be able to set a fallback language, when the preferred language doesn't exist, so instead of a string this could be an array.

I am not sure about adding another section just for this

Yes, I agree this could be set in display for the display language and in updates for the update language (#335).

[display]
preferred_languages = [ "fr", "en"]

[updates]
only_languages = [ "fr", "en"]