Page MenuHomeSolus

Please add google's IME mozc
Closed, ResolvedPublic


A (BSD 3-Clause Licensed) software for editing the selected input method, making possible the ability to change between languages such as japanese, korean, chinese, etc.


Event Timeline

gsivori created this task.Aug 22 2016, 1:20 AM

Budgie IBUS support needs to be finished before we can do anything with input methods such as this one. It is technically on hold right now due to Ikey being away, but it is set to land in 1.2.1.

JoshStrobl triaged this task as Normal priority.Sep 10 2016, 3:04 PM
DataDrake raised the priority of this task from Normal to High.Sep 20 2016, 4:14 PM
DataDrake closed this task as Wontfix.Oct 28 2016, 7:37 PM
DataDrake claimed this task.
DataDrake added a subscriber: DataDrake.

We have ibus now, so I don't see a reason for this

I still need the mozc or anthy package to be abtle to type japanese even with ibus.

In other distros you'd install ibus-mozc/ibus-anthy and then select that in the ibus preferences. It's to convert the "western" characters into japanese/chinese characters. The normal keyboard layout doesn't use japanese characters.

DataDrake reopened this task as Open.Oct 29 2016, 1:03 PM

Thank you for responding. I'll look closer at this if I get to IBUS stuff today.

DataDrake closed this task as Resolved.Nov 5 2016, 1:21 PM

@Krummer I landed ibus-anthy in unstable two days ago. It is now available in stable (shannon).

With regard to the original intent of this task: We now have support for Chinese (ibus-libpinyin) and Japanese (ibus-anthy). I will be looking at ibus-unikey (Vietnamese), and ibus-hangul (Korean) today. Because of this, I don't see a strong need for mozc support, and am closing this task.

Thanks for adding ibus-anthy support.

And still would like ibus-mozc support..... ibus-mozc performs much better as a Japanese IME, compared to Anthy from my non-optimal experience with Anthy, because Anthy gives kanji conversion suggestions that are not commonly used...
Imagine predictive typing that tries to steer you into different words very frequently...

For proficient Japanese writers/readers, mozc is clearly a winner. So, not seeing support for ibus-mozc is a show stopper for me to switch to Solus distro, actually.

joguSD added a subscriber: joguSD.Feb 16 2017, 10:11 AM

I'm gonna second adding support for mozc. It really is superior to anthy in just about every way.

gsivori reopened this task as Open.Feb 22 2017, 11:49 PM

I'm going to bump this again given that, as josuSD and GiantEnemyCrab stated, anthy does not work as expected. Not only it has no integration with other apps meaning that I would have to copy-paste written japanese text from a compatible app (like gedit) into google-chrome for instance.
mozc is clearly a winner in suggestions and when for fast typing.
Hope we get some feedback on this

gsivori lowered the priority of this task from High to Normal.Feb 22 2017, 11:51 PM

Not only it has no integration with other apps meaning that I would have to copy-paste written japanese text from a compatible app (like gedit) into google-chrome for instance.

Ibus-anthy should work just like ibus-libpinyin universally across different apps. In case it doesn't work for you, could you raise a new issue?

@DataDrake According to @gsivori, there may be legitimate reasons for inclusion of mozc, maybe worth evaluating again under the new package inclusion policy?

I'm going to have to look through how other distros build this. Honestly, I'm super disappointed in how mozc has been managed. No git tags. No tarballs. Uses the gyp build system. Its only saving grace is that they take note of the commit hashes for versions in a changelog.

@DataDrake I'd be willing to help out in packaging / maintaining some of these packages. I went through the wiki page and tutorial videos on the solus packaging system but had trouble applying it to mozc.

I know this is old but as a native Japanese speaker there really is no other alternative Japanese IME for mozc. All the others like Anthy are extremely bad at predicting words and I hope a developer will look into this to get mozc packaged for Solus.

I was about to make the jump to Solus but found out mozc is not supported so I am currently on hold, so I would greatly appreciate it if it becomes supported. Thank you in advance and sorry for the inconvenience.

nya-su added a subscriber: nya-su.EditedMay 10 2018, 11:15 AM

Agree. Mozc is now the most popular input method for Japanese linux community.
I found a site which seems written by original maintainer.

and step by step build instruction for Ubuntu 18.04 (in Japanese)

DataDrake removed DataDrake as the assignee of this task.Jul 21 2018, 6:37 PM
DataDrake moved this task from Backlog to Accepted For Inclusion on the Package Requests board.

I'll accept this on the condition that someone volunteers as maintainer.

JoshStrobl closed this task as Wontfix.Aug 16 2018, 8:07 PM
JoshStrobl claimed this task.

It's been a month since this has been accepted and marked for needs maintainer. Given nobody has stepped up to provide an accepted patch, marking as wontfix. Feel free to re-open when a patch has been submitted via the appropriate process.

masami claimed this task.Dec 7 2018, 6:48 AM
masami added a subscriber: masami.

still no mozc for solus , It's hard to believe. Not been understood how bad Anthy is. please add mozc asap.

JoshStrobl removed masami as the assignee of this task.Dec 7 2018, 8:33 AM

I tried to make ibus-mozc eopkg package and it was successful.(I tried on KDE Plasma Desktop.)
As they said, mozc is much better than anthy to write in Japanese.
I have no maintainer experience, but if it allowed,I want to be a maintainer.

pspec_x86_64.xml and package.yml :

Some tips for your package.yml:

  • Instead of cd:
cd some-dir
# Do some stuff
# Done
cd ../other-dir

use pushd and popd (more info here):

pushd some-dir
# Do some stuff
# Done
pushd ../other-dir

The reason for this is that the usage of the directory stack is very handy in packaging and is basically the norm here.

  • Split arguments into other lines if the command is too long:
iamaverylong --command --with -a --lot=of --arguments

this can be written and have the same effect as:

iamaverylong --command \
    --with -a --lot=of \

Simply, It improves readability.

Before You submit your package please take my advice, your package.yml will likely not be accepted as It is. Overall You did a great job.

@YakoYakoYokuYoku There is absolutely no rule that state that pushd/popd must be used instead of cd. I have never seen any package refused because of this.
There are however rules that say :

  • dependencies must be sorted alphabetically A-Za-z (Uppercase go first)
  • 5 digits must be used for permissions mode
  • SPDX 3.x license identifier must be enforced

@YakoYakoYokuYoku @kyrios123 Thank you for advices!
I took tips and fixed pspec_x86_64.xml and package.yml ( )

But I consider how to note licenses.
Mozc was licensed by BSD 3-Clause License. But it has many third party code and those licenses are different each other.
I checked and and added some licences which are listed on SPDX License List.
I also searched other distribution's mozc package and found they listed only licenses included in SPDX or show "BSD3-License and custom".
Should I change license notice and if should, how should I change?

gsivori removed a subscriber: gsivori.Oct 22 2019, 3:12 AM

Should I remake another package request of ibus-mozc?

This task was closed and the maintainers may not see this.

I think mozc support is very important for Japanese users( some web pages said they gave up using solus linux due to not supporting it).
I recommend to support it. ( And I volunteer for it.)

@PG_MANA ibus-mozc is still accepted for inclusion, so, if you volunteer to maintain it, you can go ahead and submit your package for review :)

YakoYakoYokuYoku reopened this task as Open.Mar 9 2020, 12:10 PM
YakoYakoYokuYoku claimed this task.
foxium added a subscriber: foxium.May 5 2020, 5:00 AM