Configuration keys appear in translation catalogs, but the built-in UI does not use their translations

[kargareteli]

Hello,

While working on a Georgian translation, I noticed several configuration identifiers offered for translation, including:

• "snd_window"
• "database_host"
• "database_dbname"
• "stream_quality"
• "database_password"

Could you clarify whether translators should translate these into readable labels or preserve the original identifiers?

I checked commit "aaae7d40389d96aac8d4cad15838e9014fd7cea0" and found the following examples.

1. "database_host": translation lookup in unreachable code

In ""src/conf.cpp", lines 2527–2538" (

motion/src/conf.cpp

Lines 2527 to 2538 in aaae7d4

	void cls_config::edit_database_host(std::string &parm, enum PARM_ACT pact)
	{
	if (pact == PARM_ACT_DFLT) {
	database_host = "";
	} else if (pact == PARM_ACT_SET) {
	database_host = parm;
	} else if (pact == PARM_ACT_GET) {
	parm = database_host;
	}
	return;
	MOTION_LOG(DBG, TYPE_ALL, NO_ERRNO,"%s:%s","database_host",_("database_host"));
	}

), the translation lookup appears after an unconditional "return":

return;
MOTION_LOG(DBG, TYPE_ALL, NO_ERRNO,
"%s:%s", "database_host", _("database_host"));

2. "snd_window": the same pattern

In ""src/conf.cpp", lines 2858–2878" (

motion/src/conf.cpp

Lines 2858 to 2878 in aaae7d4

	void cls_config::edit_snd_window(std::string &parm, enum PARM_ACT pact)
	{
	if (pact == PARM_ACT_DFLT) {
	snd_window = "hamming";
	} else if (pact == PARM_ACT_SET) {
	if ((parm == "none") || (parm == "hamming") || (parm == "hann")) {
	snd_window = parm;
	} else if (parm == "") {
	snd_window = "hamming";
	} else {
	MOTION_LOG(NTC, TYPE_ALL, NO_ERRNO, _("Invalid snd_window %s"), parm.c_str());
	}
	} else if (pact == PARM_ACT_GET) {
	parm = snd_window;
	} else if (pact == PARM_ACT_LIST) {
	parm = "[\"none\",\"hamming\",\"hann\"]";
	}
	return;
	MOTION_LOG(DBG, TYPE_ALL, NO_ERRNO,"%s:%s","snd_window",_("snd_window"));
	}

):

return;
MOTION_LOG(DBG, TYPE_ALL, NO_ERRNO,
"%s:%s", "snd_window", _("snd_window"));

Nevertheless, this string is included in the "Portuguese translation catalog" (

motion/po/pt.po

Line 1017 in aaae7d4

#: src/conf.cpp

):

msgid "snd_window"
msgstr "snd janela"

3. The built-in UI renders the original key directly

In ""src/webu_html.cpp", lines 821–822" (

motion/src/webu_html.cpp

Lines 821 to 822 in aaae7d4

	" html_cfg += \"<tr><td><label for='\";\n"
	" html_cfg += jkey + \"'>\"+jkey+\"</label></td>\\n\";\n\n"

), the generated JavaScript uses "jkey" as both the field identifier and the visible label:

html_cfg += "" + jkey + "\n";

This appears to mean that translating the standalone entries does not change the labels displayed by the built-in UI.

For translators, the intended treatment is therefore unclear. For example, should "database_host" become a localized label meaning “Database host,” or remain exactly "database_host"? Similarly, in a message such as "Invalid stream_quality %d", should the configuration identifier remain unchanged while only the surrounding text is translated?

Are these catalog entries retained for future UI translation support, or are they used elsewhere through a path I have missed?

Depending on the intended behavior, could you consider either:

• Using the translations for visible labels while preserving the original keys for configuration handling; or
• Removing unused translation markers and documenting that literal configuration identifiers should remain unchanged?

Translator comments explaining the intended treatment would also help avoid inconsistent translations.

Thank you!

[Mr-Dave]

This is a great question and I invite those that use Motion in a different language to help guide what it should do.

My intent with putting together the translations was to provide those with no English language some hint as to what the parameter means. In older versions of Motion, there was a output that would show the parameter name along with the translation in parentheses. e.g. database_host (მონაცემთა ბაზის ჰოსტი)

The reason it is in a "dead code" section is because of how Motion stores the parameters as well as how I was extracting the items to be translated using xgettext. Motion has the parameter names in a struct array and as such, the xgettext will not find or list them as something to translate.

Now, that is the why..now what to do. Honestly, there seemed to be virtually no interest in the past for introducing support for different languages. I just did it because I thought I should. I don't have a computer set up with an alternative language so that is why the logging of the parameters and different language hints seems to have dropped off. (It would be easy enough to add back if there were interest.)

For the built in UI, I'd comment that how it gets created is going to change a bit. (Instead being embedded in C++ code, it is just going to be a separate file loaded that gets values from the JSON). So, it desired, the translated meaning of the parameter name could be provided.

Or, we could just leave out the parameter names from translations.

For those of you that do see the translations, what make the most sense and what do you see across other applications? (When I looked before I could not find any precedents for best practice).

[kargareteli]

I think that you can leave out the parameter names from translations or add --add-comments=TRANSLATORS: to the existing options:

XGETTEXT_OPTIONS = --keyword=_ --keyword=N_ --add-location=file --add-comments=TRANSLATORS:

/* TRANSLATORS: Do not translate this string! */
MOTION_LOG(DBG, TYPE_ALL, NO_ERRNO,"%s:%s","database_host",_("database_host"));

and add such comments to the parameter names which are not used in the UI - do not translate this string or add an instruction how to translate the shortened string exactly. It will show such comments directly in the Poedit.

[Mr-Dave]

Not sure if these are any good but if you are interested here are the ka translations created using the automated tools.
new_ka.po.txt

[kargareteli]

I've read new_ka.po.txt but there are problems - for example, "Invalid timelapse_interval %d" is currently translated into Georgian as "არასწორი ინტერვალი დროის ინტერვალით %d", which roughly means “Invalid interval with a time interval %d.” This is incorrect and obscures the actual parameter name. Around 40–50% of the translations I have reviewed have similar problems.

I would suggest focusing translation efforts on user-facing text. Internal diagnostic and debug messages should remain in English so developers can understand the output, identify the relevant configuration parameter, and search for the corresponding message in the source code.