Change terminology on language settings

[Peeter Tinits]

Perhaps change "Either" into "Don't show", it's more transparent right away. Generally we should encourage people to use the drop-down menu instead of remove button? This would keep the data point more stable maybe.

Maybe also change "destination" to "target", it just seems more appropriate for translations.

Maybe change the text to "Languages can be added by specifying the language code or language name (as written by native speakers). You can specify whether to display each chosen language as source or target or neither for the current article. If you add a new language, also update your language skills levels in text corpus." This is to encourage people to not add/remove languages but to use the dropdown menu.

It is really great that language skills are saved even if you remove a language and add it again - this makes it much less of an issue!

In "Text corpus" Please change "proficiency" to "skill level" in the intro text. Instead of (the mistaken?) "Display" also "Skill level" should probably be used. Add numbers from 0 to 5 for the skill levels to for clarity. As in "0 - Undefined", "5 - Native".

Instead of "Default translation" and the radio buttons write "I usually (by default) [radio button] translate texts exactly [radio button] adapt the sources to fit our needs more freely."

The reasons for all these changes is to make the text most transparent for people who might not be familiar with computer terminology or translation terminology we used. As the text corpus is something they won't see in action themselves, it has to be really clear for inexperienced users.

[Kristian K]

I agree with your proposed terms. You can change them in the English translation file.

[Peeter Tinits]

Ok, I would be happy to. Unfortunately I personally don't know where these files are or how they can be changed, if we all agree. Actually, how does it work to translate it into e.g. latvian? I couldn't find any link or explanation on brief view (I looked more thoroughly some time ago too).

[Andrjus Frantskjavitsius]

Well, the documentation is lacking... Mainly because I didn't have time. I'm not proud of this!

There are message files which are composed of simple name = value pairs. To find the files, open Source and navigate to minoritytranslate/mtapplication/src/main/resources on bitbucket. The files are named messages_langcode.properties . The qqq language code is for explanations.

Since I haven't merged my changes yet, current message files can be found here.

To test your translations/fixes just place the messages file in Minority Translate/i18n folder and the application will load the language on startup.

[Kristian K]

I will start something here: http://translate.keeleleek.ee/wiki/Localization

[Peeter Tinits]

Ok, updated the linked file to the best of my abilities at pull request #42. The sequence of radio buttons needs to be changed with exact translation being the first.

[Andrjus Frantskjavitsius]

Thank you!

Did you test your changes?

[Peeter Tinits]

I did not. I'm using the .jar file, and I'm not sure where I could replace this file. So I don't really know how. Is there an installation, where I could just replace this file?

[Andrjus Frantskjavitsius]

If you are using Windows then there is a Minority Translate folder in your Documents. Place your message files under i18n subfolder.

If you are using an Unix, then the folder is locaded in your home directory ~/ .

[Peeter Tinits]

I have the MT subfolder in documents, but no i18n subfolder. I have pplugins, autosave, lists.json, MT.log, prefs.json, wikis.json.

[Andrjus Frantskjavitsius]

Yes, create the subfolder manually.

[Peeter Tinits]

Ok, didn't think of that. Now it works, looks mostly ok, - btw I don't really see the problem with long menu items.

There is one correcture I would make - it seems to me that 1 filter works backwards to other filters. They should all include more content on ticked, so I would turn the introduction only tick around to "Show the whole article".

[Peeter Tinits]

This issue is solved or continued in issue #90

[Andrjus Frantskjavitsius]

I wouldnt close this just yet.

Is the "Very good (en-3)" type selection ok?

[Peeter Tinits]

Oh, right forgot about that. I would prefer to keep the number in the front (without them, the list seems more crowding). But I may lack the information, if it looks odd to some.

(en-3) does the job too I guess. If you can technically implement it, it's an option. I'd say it's just one vote from me here: @keeleleek , @Kruusamagi what do you think?

[Ivo Kruusamägi]

I don't have any strong opinions on this.

[Peeter Tinits]

Kristian offered this possibility to include longer sentences. I am in principle agreement, we can have longer sentences from the babel extension too. But I strongly feel that we should at this point only copy them, and not have an automatic retreival structure that @keeleleek recommends. Simply because it will probably take long time and effort to make it technologically. If it is not difficult, it has its benefits though.

With longer sentences, keeping the number at the first position is really useful I think.

See pikem tekst mahub sinna kasti ära sedamoodi, et kui see valikukast on kinni, siis on see "liiga lühike" aga kui see on lahti, siis mahub sinna üpris palju teksti. Selle tõttu on sellistel dropdown menüüdel tihti pealmine kirje lühikese tekstiga "Vali". Selleks tekstikeseks võiks meie endi tõlgetest valida ehk järgmise: preferences.program.corpus.proficiency = Skill level Püüan graafiliselt selgitada:

Dropdown kinni: [ Skill level ]

Dropdown lahti: [ Skill level ] [ This user has [[$1|no]] knowledge of [[$2|$3]] (or understands it with considerable difficulty). ] [ This user has [[$1|basic]] knowledge of [[$2|$3]]. ] [ This user has [[$1|intermediate]] knowledge of [[$2|$3]]. ] [ This user has [[$1|advanced]] knowledge of [[$2|$3]]. ] [ This user has [[$1|near native speaker]] knowledge of [[$2|$3]]. ] [ This user has [[$1|professional]] knowledge of [[$2|$3]]. ] [ This user has a [[$1|native]] understanding of [[$2|$3]]. ]

Ilmselt on võimalik esiletõstud lausetes ka MTs alles jätta.

[Kristian K]

I don't know Markdown well enough to add linebreaks in the text.

Ofcourse we need not implement all languages now, but we should adopt a structure which is extendable in the future. That's why I am strongly against adding any new terms than those that are present in the Babel extension.

Dropdown kinni:

[ Skill level ]

Dropdown lahti: [ Skill level ]

[ This user has [[$1|no]] knowledge of [[$2|$3]] (or understands it with considerable difficulty). ]

[ This user has [[$1|basic]] knowledge of [[$2|$3]]. ]

[ This user has [[$1|intermediate]] knowledge of [[$2|$3]]. ]

[ This user has [[$1|advanced]] knowledge of [[$2|$3]]. ]

[ This user has [[$1|near native speaker]] knowledge of [[$2|$3]]. ]

[ This user has [[$1|professional]] knowledge of [[$2|$3]]. ]

[ This user has a [[$1|native]] understanding of [[$2|$3]]. ]

[Peeter Tinits]

One option would be to have dropdown kinni show just the word at the [[$1|no] + number (front or back), and the whole sentence when choosing the answer (dropdown lahti).

This way both could be derived from what babel has, we wouldn't need to alter anything as they context of meaning would be shown (and we can just show them in the wierd declinations given), and we wouldn't need to alter the interface much, as the final option remains very short.

Thus, the box width could be set by the longest item at the [[$1|near native speaker]] place.

Previously I also saw, that some languages do have the short ones included in babel (that is, it was designed to include them), but this seems to be more of an exception, and just include only one option. E.g. https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FBabel/master/i18n%2Fet.json

[Andrjus Frantskjavitsius]

I think this has been resolved.

Wait for the new version and review the changes. Create a new issue if something still needs done.