The new space menu: four strings cannot be translated, and the preview ignores shape icons (FluentCommunity 2.11.0)
I maintain the German catalogues for FluentCommunity, FluentCommunity Pro and
FluentMessaging, and I went through the new strings after updating to 2.11.0.
The space menu is a fine addition. Two things in it need a look, and the first
one is a regression.
1. Four strings never reach the translation map
The portal hands the map to the bundle as
js_vars['fluentComAdmin'] with 'i18n' => TransStrings::getStrings()
(PortalHandler.php:486 and :977), and the bundle resolves a string with
window.fluentComAdmin.i18n[t] || t. What is not a key in TransStrings.php
is therefore returned unchanged β English on an otherwise translated screen,
with no warning anywhere.
I checked every string that reaches this map from all five shipped bundles β
app.js, admin_app.js, onboarding.js, customizer_app.js and the Pro
bundle β against fresh .pot files for fluent-community,
fluent-community-pro and fluent-messaging. That includes the calls through
the minified module-local helper
(function W(e){return window.fluentComAdmin.i18n[e]||e}), which looking for
$t() alone would miss: 41 such calls in app.js, 53 in admin_app.js.
Four strings, and only four, are in no catalogue:
| String | Where it shows |
|---|---|
Edit a link's Placement to move it to the space sub header. |
hint under an empty "Secondary Links" section |
This is a built-in link, the URL can't be edited. |
editing a built-in menu item |
This is a page link, edit the page's slug to change the URL. |
editing a page menu item |
Enable chat for this space's members |
space settings (in the portal bundle as well as the admin one) |
None of them appears in any PHP file of either plugin, so the fix is four lines
in TransStrings::getStrings() β the same map that already carries their
neighbours on the very same screen (Primary Menu, Secondary Links,
Both rows, as members will see them). Not AdminTransStrings.php: that one
is generated and serves the settings screens in wp-admin.
The fourth one is a regression. In 2.10.01 that setting was translatable,
and so was the heading above it:
// 2.10.01, app/Services/TransStrings.php
737: 'Enable group chat for this space members' => __('Enable group chat for this space members', 'fluent-community'),
887: 'Group Chat?' => __('Group Chat?', 'fluent-community'),
In 2.11.0 both keys are gone from the file, the wording changed to
Enable chat for this space's members, and the new wording was not added back.
For a German site that means a line which read "Forenchat" in 2.10.01 now reads
English. Rewording a string is fine β it costs the old translation, and that is
the translator's problem, not yours. Dropping the key on the way is what turns
it into a defect.
Worth a grep at your end: if the rename happened by editing the component and
not the map, other strings may have travelled the same way.
2. The menu preview draws the wrong space icon
The preview at the top of the Menu tab shows the space name with its icon. For
a space that uses a shape, it draws the empty-avatar placeholder instead β
a plain coloured circle, where the portal shows the shape.
FluentCommunity supports three icon sources, and a space stores exactly one of
them (logo, settings.emoji, settings.shape_svg). The portal checks all
three:
// app.js
β¦ emoji ? <span>{emoji}</span>
: shape_svg ? <span><div innerHTML={shape_svg}/></span>
: <fallback>
The new preview checks two:
// admin_app.js, the menu preview
spaceProfile.logo ? <img src={logo}/>
: spaceProfile.settings?.emoji ? <span>{emoji}</span>
: <span/> // empty placeholder β shape_svg is never consulted
So the preview is accurate for spaces with an uploaded logo or an emoji, and
wrong for every space using a shape. On my installation that is the space I
opened the tab from, which makes the preview look broken rather than
incomplete.
There is already a component for this. It takes
config: {emoji, logo, shape_svg} plus a fallback_mark, and its own markup
builder has the full chain:
this.emoji ? `<span style="font-size: 20px">${this.emoji.trim()}</span>`
: this.shape_svg ? '<i class="fcom_shape el-icon">' + this.shape_svg + '</i>'
: this.fallback_mark
Reusing it in the preview would fix this and keep the two in step the next time
a fourth source is added.
Why this matters more in the preview than elsewhere
The preview exists to answer one question: what will members see? A preview
that silently differs from the real thing is worse than no preview, because it
is trusted. Same for the hint text under "Secondary Links": it is the one line
that explains how to move a link there, and on a translated site it is the only
English sentence on the screen.
Happy to send a PR for either part.
We are looking into this matter, thanks for the detailed post.
Tawsif Ahmed Riyad, thank you! And sorry for the workslop π₯.
Peter Claus Lamprecht, the issues have been fixed in dev. Not workslop, great findings. A very few people reports bug with such detailed findings. Thanks again.