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.
ヵ and ヶ become カ in every format, as they stand for 箇. In half-width katakana, kana with no half-width form fold to the nearest one that has: ヮ to ﾜ, ヰ and ヱ to ｲ and ｴ, ヷ-ヺ to ｳﾞ with a small vowel, and the small katakana for Ainu to their full-size forms.
This module adds no field to any model of its own; the readings live in the modules that apply the mixins to a model.
auto_awesome What this module does
AI-generated from the code · Odoo 19.0Adds a shared foundation for storing Japanese phonetic readings (kana) on records, with a settings screen to choose the kana format and optionally restrict which characters a reading may contain.
This module does not add any screen of its own for entering data; it provides building blocks that other Japanese localization modules use to give records a phonetic reading of their name.
In Settings, a new "Japanese Kana" section lets an administrator choose the Kana Format readings are stored in: full-width katakana, half-width katakana or hiragana. It also offers a "Restrict Characters" option with an "Additional Characters" field (a pattern for extra allowed characters such as letters or digits).
When a reading is saved, it is automatically cleaned up so the same pronunciation always looks the same: full-width letters and digits become half-width, extra spaces are collapsed, and the text is converted to the chosen format. Small ヵ and ヶ are stored as カ. A blank reading is stored as empty rather than as a space.
If character restriction is on, a reading containing anything other than the kana of the chosen format, spaces, or the extra allowed characters is refused with an error when saved. The check runs on the cleaned-up value.
Searching by reading also works with the cleaned-up form, so a search matches however the term was typed. For models that use the name-reading mixin, searching the display name also looks at the reading.
A format can be set per model through system parameters, which take priority over the global setting; invalid format values or invalid character patterns are rejected when saved.
Depends on
Required by other modules
Models and fields (4)
- kana.mixin · new model
- name.kana.mixin · new modelname_kana (Name (Kana)), name_kana_search (Name (Kana) Search)
- ir.config_parameter · extends an existing model
- res.config.settings · extends an existing modelkana_format, kana_allowed_chars, kana_restrict_chars
Text generated by AI (DeepSeek) from reading the Odoo 19.0 code on GitHub; it may contain mistakes, so check the code before deciding. View the code on GitHub
Availability by version
Reviewed: 2026-11-03Confirmation status: 1 confirmed, 8 with no information of 9 versions.
Sources · Odoo 19.0
Confirmed on 2026-11-03 in branch 19.0 of OCA/l10n-japan.
terminal Installation and usage
OCA documentation · Odoo 19.0Configuration
Source · Odoo 19.0Select 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.
To refuse readings with characters a receiving system cannot take, enable Restrict Characters under the same settings. A reading may then hold only the kana of its format and spaces, plus what Additional Characters allows: a regular expression matching one character, e.g. [0-9A-Za-z]. Both are checked on the reading once normalized, when it is saved, and the error names the characters refused. A model can take its own additional characters with the system parameter l10n_jp_kana.allowed_chars.<model>.
Usage
Source · Odoo 19.0Install the module that carries the reading to the model you need:
l10n_jp_kana_partner_name-- contactsl10n_jp_kana_product_name-- productsl10n_jp_kana_hr_employee_name-- employees
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.
On a model that delegates to another one (_inherits, as a product variant does to its template), inherit kana.mixin there as well. The reading is stored on the parent, and the child would otherwise keep the value as it was typed until the record is read from the database again.
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.
No verified information in OCA: Installation.
Installation instructions, the distribution package, dependencies and configuration steps are not shown because they have not yet been verified in the module documentation for any version.
Data imported from GitHub: this sheet reflects the latest catalog review, not a live lookup. Always check the module documentation and staging before installing in production.