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 xgettext wrapper #11

Merged
merged 3 commits into from
Dec 21, 2024
Merged

Add xgettext wrapper #11

merged 3 commits into from
Dec 21, 2024

Conversation

y5nw
Copy link
Contributor

@y5nw y5nw commented Dec 4, 2024

This PR adds a simple xgettext wrapper that (among other things) adds Luanti-related keywords to be recognized by xgettext.

appgurueu pushed a commit to luanti-org/luanti that referenced this pull request Dec 14, 2024
The currently established convention uses `NS` for "translation no-ops", i.e., it will be collected by a string-collecting utility but not be translated by Luanti at this place.

We don't want to mislead modders with this example into using `NS` for plural forms instead, breaking with the established convention and making use of automated tools harder.

See also: luanti-org/modtools#11
@Wuzzy2
Copy link
Collaborator

Wuzzy2 commented Dec 19, 2024

IMHO it makes sense to include the msgid-bugs email address and project-name and project-version as (optional) arguments. And maybe also --add-comments for comments directed at translators (important to explain obscure strings).

@rubenwardy
Copy link

Any idea how you might approach #2 with this?

@y5nw
Copy link
Contributor Author

y5nw commented Dec 19, 2024

IMHO it makes sense to include the msgid-bugs email address and project-name and project-version as (optional) arguments. And maybe also --add-comments for comments directed at translators (important to explain obscure strings).

The script passes user-supplied arguments directly to xgettext so users can already provide these options themselves. I don't think these options have a (simple to implement) sensible default that the script can provide otherwise.

Any idea how you might approach #2 with this?

I would suggest using a different script that collects entries from mod.conf into a Lua file. It seems like Luanti already takes a similar approach to make settings translatable: https://github.com/minetest/minetest/blob/master/builtin/mainmenu/settings/generate_from_settingtypes.lua

@appgurueu appgurueu merged commit c544b42 into luanti-org:main Dec 21, 2024
@appgurueu
Copy link
Contributor

Merged as-is, further improvements can be made later on.

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

Successfully merging this pull request may close these issues.

4 participants