[resolved]Search syntax and other issues with Spanish UI

For the search, you could try Speaker <Persona Jesus> The reason is that the Spanish translation (as all of the translations) is incomplete, and when a term is translated it is put in the other language, otherwise the English term is used. "Speaker" has been added fairly recently as a term to translate, and has not been done yet. But Person has been translated. I know this, only because I am doing the translation in Italian, but can look at what has been done in other languages. As the translations are crowd sourced and done externally to Logos by volunteers, there is not much Logos can do about it. Except pay the translators? Otherwise the UI (including the search terms) will always be a mix of English and Spanish.

Richard,

thanks for chiming in - I hope it helps the Spanish users to use Logos. But your answer points to a major usability issue in localized UIs.The same has been brought up in the German language forum as well.

I somewhat understand the rationale behind translating commands (even though I get angry about it everytime I have to input a formula in localized Excel) - after all there are users who use the localized UI because they don't speak English. But in this case, there needs to be a full licalization, not a half-baked mix. And this would include not only the non-translated commands, but the examples, the help files, the instructional training material (including videos...). To make matters worse, the crowd-sourced localization page seems to take projects offline, when Logos deems them completed, so there's no way to 'cheat' even for power users.

As you explained, this issue likely is going to stay with us and grow ever larger the more localizations there are - and every change in the software will induce a ripple effect into the local UIs.

However, I see two things Logos can do: 

• giving us a band-aid: have a list of all commands, search parameters etc. that are ever input by the user into Logos and make that a spreadsheet: first column English, then the local translations. Especially since much of the available material in the wiki, the training videos, the mobile.Ed courses etc. is only available in English, this would allow users to construct their command and searches based on the examples that are in English. And it would show which words are translated - and how! - and which are not.
  (Aside: while the clamoring about software documentation has become a bit overbearing these days, a list of computer-understood input possibilities in my opinion is crucial element of it, for all UI languages. And if Faithlife won't do the spreadsheet version, some volunteers might set this up easily on the wiki provided they get the lists in the respective languages)  
• fix the problem by leaving the Microsoft-beaten track: this track is the "a UI language is a UI language, period" approach which forces me to remember or lookup ZAEHLENWENN when I want to write COUNTIF in a formula. But given the limited vocabulary and small chance of collisions, there is no compelling reason not to have the command parser / search string interpreter recognize input in local language OR in English. This way, everybody could use existing examples or knowledge for commands and searches.