Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add config file option to set prefered language #251

Open
zed-g opened this issue Jan 4, 2022 · 8 comments
Open

Add config file option to set prefered language #251

zed-g opened this issue Jan 4, 2022 · 8 comments

Comments

@zed-g
Copy link

zed-g commented Jan 4, 2022

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
Copy link
Collaborator

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
Copy link
Author

zed-g commented Jan 12, 2022

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
Copy link
Collaborator

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
Copy link

9mdv commented Jul 14, 2023

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.

2023-07-14_103116

@niklasmohrin
Copy link
Collaborator

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

@niklasmohrin
Copy link
Collaborator

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
Copy link

noraj commented Oct 2, 2023

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"]

@aidan-gibson
Copy link

I agree this should be in the config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

5 participants