Is there a way to leverage the glossary to a translated term lookup?
For users of translated Gramps GUIs, it would be helpful it they could lookup a feature’s English name equivalent.
And to lookup the GUI element name in their native language when we use the English name in Discourse.
I regularly use Google to “site:” search our domain in order to provide hot-linked help: <SearchTerm>site:gramps-project.org/wiki
DuckDuckGo extends the site search parameter with inurl: and intitle: options. The also have language filtering. (But there’s something weird with their indexing of our site currently… the page desciptions are being restricted.)
I tried using the Weblate interface to do lookups. But that was ridiculously hard to navigate
Click on “Search” and enter a string such as “active person”. You can also click on “Languages” first and select a translation, and then click on “Search.”
Alternatively, just do a text search in the appropriate po file.
That Weblate Glossary ( ← this link starts 1 level deeper, with the search form open) is what I found to be so unnavigable.
It seems OK when you try it with a few common terms (like “active person”). But when looking deeper, it seems perverse. That “active person” sesrch only returns 5 hits? And 1 is English. How can there only be 5?
I thought that we could use the Wiki’s Glossary as an index to the documentation and a cross-reference for other languages. (Several of us having been working on the Glossary for years.) It has become pretty good as an index.
But it doesn’t work well for the other languages.
First, it is only partially translated. And only by a few languages.
Second when translating, the translated terms tend to be re-sorted alphabetically and the hash link is changed.
So while I hoped that the Turk who is given a link on Discourse to a Home Person glossary entry be redirected to “ana kişi” by just just click the Türkçe link on the Language bar. But that flushes the the hashtag link “#home_person” when it re-directs to the Turkish language Glossary.
However, the turkish translator was savvy enough to leave the SPAN tags in English. So the unusually observant user might notice that they will be re-directed to “Ana Kişi” if they insert the Language code in the right place in the english #home_person hashtagged URL:
The font names should not be translatable. And the items with a number are probably from forms but should not include the form line number.
I can delete the terms. But they will come back the next time the weblate components are regenerated.
So how should these ‘translatable string’ errors be reported so they will be fixed and the fixes can be tracked? And how do we find them in the source code?
No. They have been created by a translator to help with the translation.
Are you sure that they are errors? The font strings come from the glade file for the style editor. They look OK to me.
You can find a link to the source code if you use the Weblate search to find the string. The Program and Addons components give a link back to the source code in the sidebar.
Well, according to the translation standards, font names are considered proper nouns never translated. So my assumption is that the source code should be changed to eliminate the underscore marker. If it is in the Glade file, shouldn’t there be a ‘translatable’ option for each string?
Likewise, the 7. Sex: Male and 8. Sex: Female could probably be broken into a set of concatenations so that Sex , Male and Female are only translated once.
There hasn’t been any kind of push to reduce the string count. But if the tool that @kmikkels works the way that I hope, then we make be able to make a start on that. (Since more than 750,000 words in the program glossary is too much. Then the Addons glossary doubles that.)
I had the same thought. But what I found was the “no translation of font names” holds true for non-Latin character sets. The only possible exception was when the name oncluded a meaningful word… like “bold” or “plain”