After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743643 - Lacks scripts other than Latin
Lacks scripts other than Latin
Status: RESOLVED OBSOLETE
Product: gnome-characters
Classification: Other
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Characters maintainer(s)
GNOME Characters maintainer(s)
Depends on: 751765
Blocks:
 
 
Reported: 2015-01-28 12:58 UTC by Bastien Nocera
Modified: 2018-02-08 13:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
mock (152.88 KB, image/png)
2015-06-15 07:24 UTC, Daiki Ueno
  Details
libgc: Add API to get scripts from language (71.09 KB, patch)
2015-07-01 03:57 UTC, Daiki Ueno
committed Details | Review
categoryList: Support non-Latin scripts (10.76 KB, patch)
2015-07-01 03:57 UTC, Daiki Ueno
committed Details | Review

Description Bastien Nocera 2015-01-28 12:58:56 UTC
It should be possible to browse by script, without showing them all by default.

Maybe a way to show scripts associated with languages and input methods used on the system would be a good way to avoid showing loads of scripts in the sidebar.
Comment 1 Daiki Ueno 2015-02-07 02:25:54 UTC
It would be nice if there is a sidebar tab for a script of the current locale, but the implementation might not be straightforward, since UCD doesn't include the mapping, though CLDR has.

Alternatively, the character dialog could have a button linked to a script page, so a user could first search a character (like "katakana letter a" in Japanese), and then switch to the page containing all Katakana characters.
Comment 2 Allan Day 2015-02-10 18:14:16 UTC
(In reply to Bastien Nocera from comment #0)
> It should be possible to browse by script, without showing them all by
> default.

Can you give me a couple of use cases? I'd be happy to update the mockups.
Comment 3 Allan Day 2015-02-11 16:37:07 UTC
To elaborate on my previous point: the explicit design goal for this application is to focus on a relatively small set of use cases, rather than creating a UI for browsing every conceivable character out there.

In particular, I'm wary not to dilute or undermine the existing design, when the use cases might be so different as to require different applications altogether.

I need a lot more information. How might a character map be used for non-latin scripts?
Comment 4 Bastien Nocera 2015-02-11 16:52:01 UTC
For the same reasons that I might want to search for specific characters in latin, a Russian user might want to search for variants of cyrillic characters.

Rinse and repeat for users for which the main language's script isn't latin (Arabic, Cyrillic, Greek, etc.).

http://en.wikipedia.org/wiki/Alphabet#mediaviewer/File:Writing_systems_worldwide.png
Comment 5 Allan Day 2015-02-11 17:06:17 UTC
(In reply to Bastien Nocera from comment #4)
> For the same reasons that I might want to search for specific characters in
> latin, a Russian user might want to search for variants of cyrillic
> characters.
> 
> Rinse and repeat for users for which the main language's script isn't latin
> (Arabic, Cyrillic, Greek, etc.).
...

Any idea of the number of characters in each of those scripts?

Do the existing sections in gnome-characters make sense for them (particularly punctuation and bullets)?

What about Chinese, Japanese, and Korean scripts?
Comment 6 Daiki Ueno 2015-06-15 07:24:57 UTC
Created attachment 305269 [details]
mock

I'm not familiar with other languages, but in Japanese, we usually use three different scripts: Hiragana, Katakana, and Kanji.  The former two are considered as alphabets.  So, it might make some sense to display those characters in a dedicated page, possibly below the 'Emoticons' tab (as attached screenshot).

For the implementation, I think the simplest approach would be to let translators translate a GSettings key which lists local script names.  I've pushed an initial implementation of this to wip/dueno/local-scripts branch.

Suggestions appreciated.
Comment 7 Daiki Ueno 2015-06-15 07:34:31 UTC
In the above screenshot, "この言語の文字" means "local scripts" in Japanese, and the right pane contains Hiragana and Katakana scripts.
Comment 8 Bastien Nocera 2015-06-15 07:40:20 UTC
(In reply to Daiki Ueno from comment #6)
<snip>
> For the implementation, I think the simplest approach would be to let
> translators translate a GSettings key which lists local script names.  I've
> pushed an initial implementation of this to wip/dueno/local-scripts branch.

Being based on translations won't be good enough. You can only have one language enabled at a time, and it might not have anything to do with the languages that the user wants to be able to input.

IMO, we should have a couple of different levels of "configuration" here:
- Show all the scripts related to the currently setup input sources. If I have Russian and English keyboard layouts, I should see Cyrillic and Latin blocks.
- Make it possible for users to select which scripts to show (if they want to add more items to the list in the first item)
- Make searching search the whole set of Unicode characters, not just in the setup scripts.
Comment 9 Daiki Ueno 2015-06-16 09:22:10 UTC
(In reply to Bastien Nocera from comment #8)
> - Show all the scripts related to the currently setup input sources. If I
> have Russian and English keyboard layouts, I should see Cyrillic and Latin
> blocks.

Thanks.  That is an interesting idea, though we need to resolve mappings from languages to scripts (i.e., 'Russian' -> ['Cyrillic'], 'Japanese' -> ['Hiragana', 'Katakana']).  To build those mappings reliably, I still think using translations would be handier than maintaining them by ourselves.

So, I have just tried to implement it in the branch:

commit 235720c9d3d06fa8732da19bb41d90224da1a4a0
Author: Daiki Ueno <dueno@src.gnome.org>
Date:   Tue Jun 16 17:56:55 2015 +0900

    categoryList: Deduce languages from input-sources
    
    It first reads the input-source settings and deduce the language list.
    Then, for each language, deduce the script list from translations.
    
    This requires a couple of API additions to gnome-desktop:
    
      - gnome_xkb_info_get_languages_for_layout, which gets language codes
        associated with an XKB layout
    
      - gnome_normalize_language_code, which canonicalizes a 3-letter
        language code to a 2-letter code, so we can build a valid locale
        name
    
    https://bugzilla.gnome.org/show_bug.cgi?id=743643

Does this sound reasonable, or do you have any better idea?

> - Make it possible for users to select which scripts to show (if they want
> to add more items to the list in the first item)
> - Make searching search the whole set of Unicode characters, not just in the
> setup scripts.

Those shouldn't be so difficult, once the scripts selection is implemented.
Comment 10 Bastien Nocera 2015-06-16 10:36:30 UTC
(In reply to Daiki Ueno from comment #9)
> (In reply to Bastien Nocera from comment #8)
> > - Show all the scripts related to the currently setup input sources. If I
> > have Russian and English keyboard layouts, I should see Cyrillic and Latin
> > blocks.
> 
> Thanks.  That is an interesting idea, though we need to resolve mappings
> from languages to scripts (i.e., 'Russian' -> ['Cyrillic'], 'Japanese' ->
> ['Hiragana', 'Katakana']).  To build those mappings reliably, I still think
> using translations would be handier than maintaining them by ourselves.

This is very brittle, and I don't understand why you need to use GSettings for that, when you always get the default value of the key anyway.

We need to extend the gnome-desktop code and possibly the XKB layouts to export the Unicode block/Script to use for each language.

Maybe we can ask the maintainer of this site to help:
http://www.ontopia.net/i18n/index.jsp 

<snip>
> Does this sound reasonable, or do you have any better idea?

It's reasonable, though hacky.

Another way might be to generate metadata directly from the XKB layouts:
- Parse the each of the files in /usr/share/X11/xkb/symbols/
- Make a list of unicode blocks used to generate all the characters listed
- When those XKB layouts are used, use the unicode blocks detected

This doesn't cover IBus at all though. Is there no API to gather that information from IBus?

> > - Make it possible for users to select which scripts to show (if they want
> > to add more items to the list in the first item)
> > - Make searching search the whole set of Unicode characters, not just in the
> > setup scripts.
> 
> Those shouldn't be so difficult, once the scripts selection is implemented.
Comment 11 Daiki Ueno 2015-07-01 03:57:06 UTC
Thanks for the suggestion.  So, for the time being, I guess we would need to maintain some mappings by ourselves.  After a bit of research, I came across:
http://cldr.unicode.org/development/updating-codes/update-language-script-info/language-script-description
which might be sufficient for our use.

Here are what I've come up with since the last update:

- maintain language-to-scripts mapping ourselves, using the CLDR data and a generator script

- stop adding extra pages for a non-Latin language.  Instead, rename "Latin" tab to "Letters" to accommodate those characters, to make the design changes minimal

- support IBus input-sources
Comment 12 Daiki Ueno 2015-07-01 03:57:27 UTC
Created attachment 306465 [details] [review]
libgc: Add API to get scripts from language
Comment 13 Daiki Ueno 2015-07-01 03:57:39 UTC
Created attachment 306466 [details] [review]
categoryList: Support non-Latin scripts

This patch renames the "Latin" page to "Letters" and add user's
local characters into that page.  The local characters are deduced from
input-source settings.
Comment 14 Daiki Ueno 2015-07-02 07:15:42 UTC
Attachment 306465 [details] pushed as 336114f - libgc: Add API to get scripts from language
Attachment 306466 [details] pushed as 5e086c9 - categoryList: Support non-Latin scripts
Comment 15 GNOME Infrastructure Team 2018-02-08 13:14:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-characters/issues/2.