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

Localization support #58

Closed
6 of 7 tasks
michaelrsweet opened this issue Nov 1, 2020 · 2 comments
Closed
6 of 7 tasks

Localization support #58

michaelrsweet opened this issue Nov 1, 2020 · 2 comments
Assignees
Labels
enhancement New feature or request priority-medium
Milestone

Comments

@michaelrsweet
Copy link
Owner

michaelrsweet commented Nov 1, 2020

Add support for localization of the web interface using any string resource files that are added.


Breaking this down into sub-tasks:

  • Add pappl_loc_t type and structure to hold per-printer localization information.
  • Add cups_array_t *localizations array to pappl_system_t structure to cache the various localizations.
  • Add pappl_loc_t *papplSystemFindLoc(pappl_system_t *system, pappl_printer_t *printer, const char *language), papplLocFormatString(pappl_loc_t *loc, char *buffer, size_t bufsize, const char *key, ...), and const char *papplLocGetString(pappl_loc_t *loc, const char *key) APIs, plus corresponding private functions _papplLocCreate and _papplLocDelete.
  • Add pappl_loc_t *papplClientGetLoc(pappl_client_t *client) API to return the localization associated with the client's Accept-Language header.
  • Update papplClientHTMLPrintf and papplClientHTMLPuts to try localizing their inputs using the (cached) localization info and to set/restore the POSIX locale so that numbers are formatted properly.
  • Add base localizations for EFIGS
  • Add unit tests

Might be able to internally base the caching on the strings files we are pulling instead of just on the printer since many printer applications won't use per-printer localization files but instead set them at the system level.

@tillkamppeter
Copy link
Contributor

Currently vendor options look ugly:
Screenshot from 2020-11-16 00-07-24
Option/choice names are the human-readable strings of the PPD file "translated" to IPP keyword syntax. One understands them but real human-readable strings in the web interface would be great.

@michaelrsweet michaelrsweet modified the milestones: v1.1, v1.2 Jan 15, 2021
michaelrsweet added a commit that referenced this issue Mar 13, 2022
Still need to implement positional parameter support and handle R-to-L
languages.
@michaelrsweet
Copy link
Owner Author

All done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority-medium
Projects
None yet
Development

No branches or pull requests

2 participants