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.
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.
@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.
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
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?
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.
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.
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)
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.
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 : https://github.com/PG-MANA/solus-ibus-mozc
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 \ --arguments
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
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 https://github.com/google/mozc#license and https://github.com/google/mozc/blob/master/src/data/installer/credits_en.html 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?
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.)