Provides the abstract models that give a phonetic reading (カナ / ふりがな) to a model – of its name, or of any other field – and the setting that chooses the kana format readings are stored in.
A reading is stored in a canonical form, so the same pronunciation matches however it was typed: kana take the configured format, full-width ASCII and digits fold to half-width (ＡＢＣショウジ is stored as ABCショウジ), and spacing collapses to single half-width spaces. A search term goes through the same normalization before it is compared.
This module adds no field to any model of its own; the readings live in the modules that apply the mixins to a model.
Table of contents
Select the kana format under Settings > General Settings > Japanese Kana. Full-width katakana is the default; half-width katakana and hiragana are the alternatives.
A single model can depart from that, for the case where personal furigana is kept in hiragana while contacts and products stay in katakana. This is rare, so it has no setting of its own: add a system parameter under Settings > Technical > System Parameters whose key is the model name appended to the global one, and whose value is one of full_width_katakana, half_width_katakana or hiragana.
| Key | Applies to |
|---|---|
| l10n_jp_kana.format | every model with a reading |
| l10n_jp_kana.format.res.partner | contacts |
| l10n_jp_kana.format.hr.employee | employees |
| l10n_jp_kana.format.product.template | products and their variants |
An empty or absent per-model key means the model follows the global format.
Changing a format affects only the readings saved afterwards – see Known Issues.
Install the module that carries the reading to the model you need:
To give another model a reading of its name, inherit kana.mixin and name.kana.mixin alongside the model and add the name_kana field to the form and list views. In the search view, use name_kana_search rather than name_kana: a search view compares the term to the column as typed, and that field is what normalizes the term first. Readings are then normalized on create and write, and a term typed into the model’s lookup finds the record whichever kana form it is in.
For a reading of something other than the name – an address, say – inherit kana.mixin alone and declare the Char fields with kana=True. They are normalized on create and write like a name reading; add an onchange on them if the form should show the stored form before saving.
name.kana.mixin needs kana.mixin beside it, which is where the normalization lives. Neither derives from the other, so a module extending kana.mixin reaches every model that took it.
Changing a kana format does not rewrite the readings that are already stored. Only readings saved after the change follow the new format; the older ones keep the format they were saved in, and because a search term is normalized to the current format, they stop being found by it until they are saved again.
Pick the format when the module is installed. If it has to change afterwards, re-save the affected readings separately – writing a reading back through the ORM normalizes it to the current format.
Bugs are tracked on GitHub Issues. In case of trouble, please check there if your issue has already been reported. If you spotted it first, help us to smash it by providing a detailed and welcomed feedback.
Do not contact contributors directly about support or help with technical issues.
This module is maintained by the OCA.
OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.
Current maintainer:
This module is part of the OCA/l10n-japan project on GitHub.
You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.