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

Fallback to Compose file in locale directory if no mapping exists in compose.dir #318

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JSkold
Copy link

@JSkold JSkold commented Apr 8, 2023

I've created and distribute a custom locale that a mix between my native language's locale and en_US. There unfortunately seems to be no way for me to extend the compose.dir file to include a mapping for my new locale.

This MR add a new fallback in case a compose.dir entry is missing for the current locale and will cause libxkbcommon to use the compose file at:
/usr/share/X11/locale/en_XX.UTF-8/Compose
In this case en_XX is missing from compose.dir.

If no mapping exist in compose.dir for the current locale, then fallback
to the Compose file in the directory of the locales name in the systems
locale directory.
@bluetech
Copy link
Member

Do you also create a custom Compose file for your locale?

@JSkold
Copy link
Author

JSkold commented Apr 11, 2023

In my case I just have a simple Compose file with:
include "/usr/share/X11/locale/en_US.UTF-8/Compose"

But with this change anyone shipping a non-standard locale could bring their own Compose file. My use case is primarily to get dead keys to work without having every user put that line in their XCompose in their home directoy.

@bluetech
Copy link
Member

While having a custom locale is probably rare, having a custom locale and a custom Compose is surely very rare. Most people will want to fallback to the en_US.UTF-8 Compose.

Current status quo is that if you're using a custom locale, you have no solution.

With this PR, if you're using a custom locale, Compose is still broken, but you can fix with an additional step of adding an /usr/share/X11/locale/en_XX.UTF-8/Compose file with the magic include incantation. This seems not much better to me than adding this include line to your ~/.XCompose or setting XCOMPOSEFILE (both of which take precedence over the locale).

I think the preferable state would be that, if you're using a custom locale, you fall back to en_US.UTF-8, with (optionally) some provision to provide a custom file. However, this will need to be considered carefully, as doing it naively means xkb_compose_table_from_locale will no longer fail on bad/misspelled locales, which is not great.

@JSkold
Copy link
Author

JSkold commented Apr 11, 2023

In my case fallback to en_US.UTF-8 would work, but I don't like to assume that is what everyone wants. My hope is that any locale should just be able to be installed like any other package.

The benefit of checking for a fallback is that the administrator does not need to make additional configuration and the locale would work just like any other. A package would ship with two files:
/usr/share/i18n/locales/en_XX
/usr/share/X11/locale/en_XX.UTF-8/Compose
and it would "Just Work". In the other case the administrator would have to either configure every user to have a specific ~/.XCompose or put XCOMPOSEFILE in something like /etc/environment. It works but it's more unnecessary steps for the administrator to take.

@wismill wismill added enhancement Indicates new feature requests question Indicates that an issue, pull request, or discussion needs more information compose Indicates a need for improvements or additions to Compose handling labels May 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compose Indicates a need for improvements or additions to Compose handling enhancement Indicates new feature requests question Indicates that an issue, pull request, or discussion needs more information
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants