Fixed untranslated languages on My Settings #647
Conversation
ezequielpereira
commented
Jan 9, 2016
ezequielpereira
commented
- Now the languages names are translated to the language they represent
- Depends on Added PyICU package dependance sugar-build#37
- Fixes SL#4449
- This is a GCI 2015 task: https://codein.withgoogle.com/tasks/4902925285457920/
|
How will this generate a list of lang names to be translated and put on potlee? |
|
It won't... Maybe I misunderstood the task? |
|
I think so. My interpretation has been to display the language names as they would be in their language. Eg. Don't display Indonesian or Spanish (current behaviour), say Bahasa Indonesia or Espanol. the ticket has a good comparison of data sources for this. |
| @@ -132,16 +134,20 @@ def _add_row(self, locale_code=None): | |||
| language_palette = [] | |||
| key_list = self._language_dict.keys() | |||
| for language_key in sorted(key_list): | |||
| locale = Locale(self._country_dict[language_key][0][0][:2]) | |||
There was a problem hiding this comment.
[language_key][0][0][:2] woah!
What does this mean?
Can we use one of the variables like locale_code? Or can we give this a name?
There was a problem hiding this comment.
It was a workaround to obtain the language code from the language name (i.e. 'es' from 'spanish').
Now I created a dictionary with all the codes (Just for clarity).
|
I have not tested but this appears to fix the ticket. Adding the pyicu package as a dep is not an issue size wise, tested on clean SoaS22 iso which said it added less than a MB installed and did not have any sub-deps (only the pyicu package was needed). It is also within reason; discourse on the ticket found it to be fastest and most extensive list of languages. Do you foresee any issues with this new dep (@quozl?) Is it too late in the cycle to add a new dep? (@tchx84?) |
* Now the languages names are translated to the language they represent * Depends on sugarlabs/sugar-build#37 * Fixes SL#4449 * This is a GCI 2015 task: https://codein.withgoogle.com/tasks/4902925285457920/
|
Sam, can you please review this task after the patch is merged? |
|
@ezequielpereira, @samdroid-apps, a couple questions:
|
|
|
@samdroid-apps @ezequielpereira my feeling is that PyICU does a lot more than just "translate" these strings properly, it is probably a whole i18n system by itself (parallel to gettext). That might be what @manuq meant when he said [1]: If I am correct, we should not add a whole new i18n system just for one bug that can be fixed in other ways. Note this is not just about "adding one more dep", is about understanding what it means to add each new dependency. |
|
@tchx84 It should be possible then to create the necessary .po files (I don't know how to do that though). Or I can make a dictionary in extensions/cpsection/language/view.py with all the languages translated. |
|
@ezequielpereira @samdroid-apps Yes, in fact it has been done in the past [1]. [1] https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/speech.py |
|
@tchx84 I will do that if you think it is better (So we don't need to use PyICU at all). |
|
+1 to including the language names. But we should document this somewhere On Mon, Jan 11, 2016 at 9:33 AM, Ezequiel Pereira [email protected]
Walter Bender |
|
Remember we already included a list of languages in sugar-toolkit-gtk3, https://github.com/sugarlabs/sugar-toolkit-gtk3/blob/master/src/sugar3/speech.py#L49 On Mon, Jan 11, 2016 at 11:53 AM, Walter Bender [email protected]
Gonzalo Odiard |
|
Those languages are translated like "Spanish" to "Español" and "Greek" to "Ελληνική"? That's what we want to do. |
|
One issue is that the languages names are taken from espeak, then some are On Mon, Jan 11, 2016 at 12:16 PM, Ezequiel Pereira <[email protected]
Gonzalo Odiard |
|
My idea was to make a dict like this one: https://gist.github.com/ezequielpereira/2aee4f3fa1f6a37cd68a |
|
@ezequielpereira, then you show every language in they own language? |
|
@godiard Yes, because if they are in English, the people could not know which one to choose because it could be written different (For example, Spanish in Spanish is "Español", it is very different from the English spelling). |
|
@ezequielpereira, have sense. Probably is a good idea for GCI, and could be included in the next Sugar version ( @tchx84 can confirm, but I think is too late for 0.108) |
|
Why assume that the user can read or understand the language of the Sugar instance they receive or first start to use? Would it not be better to assume that the user desiring to set the interface to a different language will recognize that language written in the native script and spelling? |
|
@godiard @ezequielpereira String freeze due is on Friday [1], so it will depend on the complexity of the patch and the quality of our review. |
|
I can add the dictionary with the languages translated in their own languages, but I don't know if you all agree with that or want to do something different. |
|
@ezequielpereira, @tchx84, in this case, where there are changes visible for the user, I think would be good discuss the proposal in the list. I agree with the proposal, but @FGrose can disagree. Of course it is possible work in a patch to try, but would not be good include a change like this at the last moment without a proper discussion. Not all the changes are Features, but this one looks as a Feature. |
|
@godiard Okay, then, should I close the PR's and wait for a resolution? |
|
No need to close. |
|
Consider the situation where you receive or step up to a computer where the language had been changed to a script you could not recognize. How would you find your native or another language? Consider also how Wikipedia presents alternate languages, https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page. We try to follow that pattern in the Sugar Labs wiki sidebar, https://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki, |
|
Yep, this change missed the feature freeze, however we could target it for this release. Maybe start a mailing list thread to document the proposed approach and feature? |
|
Was a mailing list thread started? |
|
ping |
|
As @FGrose pointed out; one of the purposes of the language list is so you can find your own language, and the best way to do that is using your own language. I'm frequently failing to find English and tend to fix it by deleting the .i18n file and restarting. Ingles isn't what works for me. I think of it as a brand of fridge. 😁 |
|
I was looking around and found this small library (~20KB) which is almost perfect for this use-case. import iso639
iso639.to_name('sv')
u'Swedish'
iso639.to_native('sv')
u'svenska'BUT The data is a little incomplete and stored in a weird-flexible-format. Would it be better to include the whole library and push any improvements upstream or re-factor its data (MIT License) for our own use (say as a dictionary) and implement the interface ourselves ? |
|
On Tue, 2017-01-17 at 09:23 -0800, yatinmaan wrote:
I was looking around and found this small library (~20KB) which is
almost perfect for this use-case.
Its just a text file and an python wrapper to get the data from file.
import iso639
iso639.to_name('sv')
u'Swedish'
iso639.to_native('sv')
u'svenska'
BUT
The data is a little incomplete and stored in a weird-flexible-
format.
ISO-693-2/B | ISO-693-2/T | ISO-693-1 | NAME | NATIVE-NAME
aar | |aa | Afar |Afaraf
spa | |es |Spanish; Castilian|español
arc | | |Official Aramaic (700-300
BCE); Imperial Aramaic (700-300 BCE)|
So , would it be better to include the whole library and push any
improvements upstream or re-factor its data (MIT License) for our own
use (say as a dictionary) and implement the interface ourselves ?
The data is not MIT licensed in this project. According to the readme,
it is from US Library of Congress data:
http://www.loc.gov/standards/iso639-2/php/code_list.php
It looks very complete to me (from the table on the US LOC site). The
only column with gaps is the "ISO 639-1 Code" which is the 2 letter
language code. I assume that is because not every language has a 2
letter code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
--
Thanks,
Sam
https://www.sam.today/
Latest blog post: How they track you: Email Service Provider Edition - http://localhost/blog/how-they-track-you:-email-service-provider-edition/
|
|
Sorry, I thought the library's licence applied to the data as well. The native names thought are from Wikipedia so are licensed under CC-SA. |
|
Isn't this the chance to build our own "language" module?
Like sugar.misc.language that have functions to get current language,
and set current language etc.
AFAIK developers then to use os environ or something like that to get
current language, in activities.
…On 1/18/17, yatinmaan ***@***.***> wrote:
Sorry, I thought the library's licence applied to the data as well. The
native names thought are from Wikipedia so are licensed under CC-SA.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#647 (comment)
--
Ignacio Rodríguez
|
|
So I created an native.po (in sugar/po/) with and used gettext to "translate" language names to their native names. locale = gettext._localedirs[gettext.textdomain()] #gets the locale of current domain
def _language_native(msg):
native = gettext.translation(gettext.textdomain(),locale,languages=['native']) #gets translation from native.po
res = native.gettext(msg)
return resI choose this way so that translators can themselves add native name translations when future languages are added but I don't know if this advantage is big enough to warrant such an 'hacky' solution and wanted to know if this approach is acceptable. Some Questions:
2.1 How should I arrange the translated names, right now हिन्दी(Hindi) is placed among other 'H' names and Espanol is placed among other 'S' names (ie. in the place of Spanish)? 2.2 Wikipedia,it seems, sorts names in order of popularity/number of articles, can/should we do something like that? Thanks, |
|
1, sure we can talk here |
|
@yatinmaan: 1: yes. 2.1: sorted. 2.2: yes, with a toggle. I'm also fine with discussion here; but this is a pull request from over a year ago and the requirements or priorities may have changed since. Sorting is very helpful for locating languages in a list; but it assumes enough literacy about alphabetic order, and you will also have to choose which alphabetic order to use; which depends on language. Sorting by popularity is unfair to minorities; but a separate list of previously used or likely language choices could be provided instead. Some UX have provided a map to limit choices, but that's a whole different problem. For OLPC, I'm not very concerned about the language list feature because with the new laptops we're producing we are pre-loading Ubuntu, which asks for language during first boot and removes the unselected languages. The language list in Sugar has very little use after that happens. So it would appear the feature is more Fedora focused. The ticket #4449 is very out of date; hasn't been updated with some of the discussion in this pull request, so it would be a good idea to work toward consensus of requirements and open a new ticket, closing the old one. There might be another ticket already. The consensus seems to be; for each language, show the name in that language, and show the name in the configured language. |
|
Using this file for translations (native names from wikipedia), I get There's an issue here:Some glyphs are missing here as well as in the logger activity BUT these glyphs do appear when the log is viewed in gedit on ubuntu, so maybe sugar is missing these fonts or something. What should I do about this? As for sorting the language list :
PS : is https://bugs.sugarlabs.org active ? Thanks, |
|
Missing glyphs will be missing fonts on your system; you'll have to find an appropriate font. On the other hand, to avoid having every font installed, you might detect missing font somehow and render the boxes as blank. Yes, you can't order the languages that don't use the alphabet being used for ordering. A recursive conflict. Put them at the end of the list. I don't understand what you mean about "Ingles(English)"; the name of English in English is English. Yes, popularity is also useful, but is a different view. As tabs? Yes, bugs.sugarlabs.org is active; I've just tested it using my account. What's your observation? |
Thanks, |
I don't see why.
Yes, Arabic is a right-to-left language implementation.
Use the Timeline and the bugs mailing list to assess whether the service is in use enough for your needs. Yes, the number of bug reports has declined precipitously, and the causes are less testing and an approval filter for creating tickets.
Issues feature of GitHub is not enabled for this repository. Use bugs.sugarlabs.org. See related bug #4869 and the consequent changes in git. You are welcome to fix the problem. I'm not interested in fixing it myself because we don't plan to need this feature on our Ubuntu-based laptops, as I mentioned earlier. |
|
Closed in #961. |
