Description
PR #581 introduced locale-aware minimum content length checks across AI features. That helped align gating AI Features with user’s locale: CJK and similar locales can use a character-based count, while other locales use a word-based count via WordPress’ _x( 'words', 'Word count type. Do not translate!' ) language-pack behavior.
However, one important drawback is that the gate is based on the WP/user locale, not the language of the actual post content. In multilingual publishing workflows, those can differ. For example, a site or user profile may be set to English while the author writes Japanese, Chinese, Korean, Thai, or similar content. In that case, _x() continues to resolve to words, but the content naturally needs a character-based count. The result is that AI feature buttons can remain disabled even when the post has enough meaningful content.
Gutenberg (upstream) may use the locale-aware strategy for displaying word count at the sidebar, which is informational. Here, the same strategy controls whether a feature is available, so the consequence is more significant.
I’d like to use this issue to discuss the best approach here. My current preference is to standardize these gates on characters_excluding_spaces. That would make the checks deterministic, avoid false negatives for CJK (or similar) content under word-count based locales, and keep the threshold semantics consistent across users.
There is also a related consistency concern today: a minContentLength value of 15 means “15 characters” for character-count locales, but “15 words” for word-count locales. While expressiveness is not directly comparable across languages, using the same scalar for different units makes the gate inconsistent, especially in multilingual setups.
| EN |
JA |
 |
 |
If this is already tracked elsewhere, or if this behavior is intentional for now, please feel free to close this issue.
Step-by-step reproduction instructions
- Set the language to English.
- Create a new post with sufficient CJK, or similar non-space-delimited content.
- Observe that the AI feature buttons remain disabled, even though the post contains enough meaningful content.
Screenshots, screen recording, code snippet
No response
Environment info
- AI Plugin: Latest (develop)
Please confirm that you have searched existing issues in the repo.
Please confirm that you have tested with all plugins deactivated except the AI plugin.
Please confirm which theme type you used for testing.
Description
PR #581 introduced locale-aware minimum content length checks across AI features. That helped align gating AI Features with user’s locale: CJK and similar locales can use a character-based count, while other locales use a word-based count via WordPress’
_x( 'words', 'Word count type. Do not translate!' )language-pack behavior.However, one important drawback is that the gate is based on the WP/user locale, not the language of the actual post content. In multilingual publishing workflows, those can differ. For example, a site or user profile may be set to English while the author writes Japanese, Chinese, Korean, Thai, or similar content. In that case,
_x()continues to resolve to words, but the content naturally needs a character-based count. The result is that AI feature buttons can remain disabled even when the post has enough meaningful content.Gutenberg (upstream) may use the locale-aware strategy for displaying word count at the sidebar, which is informational. Here, the same strategy controls whether a feature is available, so the consequence is more significant.
I’d like to use this issue to discuss the best approach here. My current preference is to standardize these gates on
characters_excluding_spaces. That would make the checks deterministic, avoid false negatives for CJK (or similar) content under word-count based locales, and keep the threshold semantics consistent across users.There is also a related consistency concern today: a
minContentLengthvalue of 15 means “15 characters” for character-count locales, but “15 words” for word-count locales. While expressiveness is not directly comparable across languages, using the same scalar for different units makes the gate inconsistent, especially in multilingual setups.If this is already tracked elsewhere, or if this behavior is intentional for now, please feel free to close this issue.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
Please confirm that you have searched existing issues in the repo.
Please confirm that you have tested with all plugins deactivated except the AI plugin.
Please confirm which theme type you used for testing.