Translation priority in plugins

Development
1

I’m working on a plugin. Text strings are in english and I have a swedish translation file. Unfortunately it sometimes picks up the wrong translations from “somewhere”, I assume it is because the string is already translated in Gramps.

Is there a way to give my translation higher prio within the plugin?

Example: “Handle” is translated to “Hantera” which is correct in the context “I will handle this”, but not in “this is a handle to”.

I guess the workaround is to not use “real strings” in the code but some unique placeholders. But it makes the code harder to read and I will also need to add english translation file. What will happen for other laguages without a translation file? Will they pick the english translation or just show the placeholder?

I found a similar question from a few years ago: Translations/gettext - make context the norm?

2

No, but you can add a context if your new string differs in context from that in core Gramps.

In you code you can use:

_("string", "context")
3

@Bigfoot In the example you gave, the string context was definitely misunderstood. And you are right that it was mistranslated. So a suggestion should be made in Weblate of a more appropriate string. (databaspostreferens rather than hantera?) And that change will flow through to your plugin.

Weblate is the tool used by the Gramps-project to manage translating of strings across various languages.

Once you sign up for a free account on Weblate, you can search the Swedish cross reference:

This search for the hantera translated string found it as an individual word. (Look in the details for the occurrences in the Gramps ‘component’ sources code.

https://hosted.weblate.org/translate/gramps-project/gramps/sv/?checksum=898bf70107f08bb7&q=hantera+state%3A%3E%3Dtranslated+&sort_by=-priority%2Cposition

Weblate found :

Hantera (capitalized):

hantera (lower case):

Example in tag.py can be found in line 152:

4

Your direction here is important but the workflow is unclear.

It assumes that:

  1. the translations have been searched in Weblate
  2. it was discovered that the source/target string already exists in Weblate.
  3. and that inspecting the source code confirmed that the existing translation (target string) was appropriate for the context of the marked translatable source string .

In this case, the assumption failed in the 3rd criteria. When the string ‘handle’ exists as part of larger strings, the current hantera translation is appropriate in those contexts as a verb. But as an individual word, the context clearly indicates a noun, making the current translation is incorrect. So the _("string", "context") would work but be complicated by there being 15 occurrences. Wouldn’t all 15 need to have the explicit context if 1 entry needs it? But since all 15 have the same context, that makes more work.

But if this case had satisfied those criteria, what would the workflow be to use the workaround?

Something like this?:

  1. Obviously the first step is checking the criteria and verifying a context parameter is needed.
  2. the developer adds an explicit _("string", "context") context hint to their source code
  3. they submit a PR for the _("string", "context") change
  4. after review, the PR is merged
  5. after the merge, some criteria nudges the Translation Coordinator (volunteer needed) to submit a Weblate PR
  6. some other criteria, an admin merges the Weblate PR
  7. the string becomes available in Weblate
  8. Translators notice the waiting untranslated string and submit a translation suggestion
  9. the suggestion is approved
  10. something causes the Translation Coordinator to submit a PR for the Gramps source or Addon source
  11. the admin approves the PR and merges
  12. the changes wait until there minor public release of Gramps
  13. something causes Gary Griffin to rebuild Addons that have the string and expedite publishing an Addon List .json

(I really hope that the workflow is not this convoluted and involve that many gatekeepers.)

5

Yes, and if a new context is required it is treated just like any other new string.

Unfortunately English speaking developers may not know if a context is required when they write the code.

6

@Bigfoot

In the specific case of Handle/handle and Hantera/hantera, it would be effective to submit 2 ‘suggestions’ in the Swedish Weblate component for Gramps to resolve the Swedish issue. (Nick is also right that adding a context note in the 17 Gramps Core strings could help translators in other languages. And any “Handle” string that you mark as translatable should use the same “context”. Otherwise, Weblate will add duplicate listings that confuse everyone.)

So… what is the Swedish translation that you would recommend for a handle database record identifier? We can make that suggestion in Weblate for you.

7

@Nick-Hall

What will happen if @Bigfoot creates a po subfolder, a po/template.pot, and po/sv-local.po in their experimental plugin’s folder? Would that localization take priority?

Or would generating the locale/sv/LC_MESSAGES/addon.mo in their experimental plugin’s folder? Would that localization take priority?

8

The core Gramps translations are checked first and then the addon translations are specified as a fallback.

9

The workflow of 13 steps is far more difficult than reality. The flow is different for gramps vs addons. For addons, when a string is added or changed or context is added, a PR is created. Then it follows this flow:

  1. PR for string (or context) is created
  2. After a window of time, PR is reviewed and merged/published. If the PR contains either an update to template.pot OR has a string change, the string is sent to Weblate (as part of the PR publishing). This is steps 4-7 in your list.
  3. Translators translate. There exists exactly one Weblate PR at a time. Each translation gets added to that open Weblate PR. This is steps 9-10
  4. After there are a significant number of changes in the PR, it is merged. I am changing my process to include publishing Addons impacted when the Weblate PR is approved. This is steps 11-13.

This should allow the Addons to get the new translated string more quickly yet not have too many extra releases. I am working the bugs out of this process currently.

10

Thanks for the information.
(Regarding the swedish translation of “handle” I suppose “handtag” is the correct translation. But when used as a technical computer term most tech people would probably prefer the english “handle”.)

11

Prompting Perplexity AI with:
When translating English technical documentation for database engineering to Swedish, what is the preferred/common translation of ‘handle’ when used in the context of an ID for a database record?

Perplexity responds:

In Swedish technical/database documentation, handle in the sense of an ID used to refer to a database record is most commonly translated as referens or referens-ID

Typical usage

  • handle → referens
  • record handle → postreferens or referens till posten
  • database handle in a UI/API sense may also be kept as handle if the English term is established in the codebase, but Swedish prose usually prefers referens.

Practical recommendation

For documentation aimed at Swedish readers, I would usually write:

  • postreferens if it means an internal identifier for a specific record.
  • referens-ID if you want to make the “ID” aspect explicit.
  • nyckel only if the text really means a key in the database-design sense, not a UI/API handle.
    If you want, I can suggest the most natural Swedish phrasing for the full sentence you’re translating.