My name is Котов Андрій (GitHub: @kotovav81). We have prepared an expanded Ukrainian (uk) localization for Carbonio CE and would like to contribute it to official releases. This is a contribution/review request, not a product support incident.

Our GitHub tracking issue was automatically closed with instructions to use this forum:
<a href=" removed link "> removed link

The following 11 pull requests are currently open:

• Mail: <a href=" removed link "> removed link

• Calendar: <a href=" removed link "> removed link

• Contacts: <a href=" removed link "> removed link

• Files: <a href=" removed link "> removed link

• Shell translations: <a href=" removed link "> removed link

• Ukrainian selector label: <a href=" removed link "> removed link

• User Login: <a href=" removed link "> removed link

• Admin Login: <a href=" removed link "> removed link

• Auth UI: <a href=" removed link "> removed link

• Tasks: <a href=" removed link "> removed link

• Workstream Collaboration: <a href=" removed link "> removed link

English is the source of truth. Existing Ukrainian translations are preserved except explicit reviewed corrections. New translations are AI-assisted EN → UK with manual review; maintainer linguistic review is welcome.

Changed values have been checked for placeholders and supported markup, and our tooling has 24 passing unit tests. An earlier installed revision is being tested by internal users, particularly in Mail and Calendar.

We do not claim 100% coverage: twelve keys have empty English source values, and current Files upstream introduced four additional strings. These gaps are disclosed in the PRs. Current Admin Console coverage is not claimed.

We also prepared a separate minimal Shell source patch registering uk in the language selector and loading Ukrainian date-fns locale data. Against fresh upstream, its two tests, TypeScript check, targeted ESLint, package and library builds passed.

GitHub temporarily blocked creation of the remaining forks; the functional Shell and Storages PRs are not yet open.

Project and technical details:

Project: <a href=" removed link "> removed link

Submission details: <a href=" removed link /blob/main/docs/submission-2026-10-13.md"> removed link /blob/main/docs/submission-2026-10-13.md

Tested Shell patch: <a href=" removed link /blob/main/patches/shell/0003-current-upstream-uk-locale-with-tests.patch"> removed link /blob/main/patches/shell/0003-current-upstream-uk-locale-with-tests.patch

Could a moderator please direct this contribution to the localization and Web Client maintainers?

We would appreciate guidance on:

1. Review/acceptance of these PRs or importing them into your translation platform.

2. Including accepted translations in official localization packages removed link

3. Enabling Українська in the Web Client language selector.

4. The correct context for empty English values and the current Admin Console translation source.

The translation CONTRIBUTING pages link to carbonio-ce-contribute; please confirm the current contribution channel if that page has moved.

No branding, private URLs, credentials or production-specific changes are included in these contributions.

We are ready to help maintain the translation and incorporate feedback.

Thank you,
Котов Андрій (@kotovav81)

After a Class of Service is deleted, accounts that still reference it keep the dangling zimbraCOSId. LDAP-side lookups fall back to the default COS, but the mailbox service keeps serving the old COS's values from its account cache, so the two views of the same account disagree until the account cache is flushed.

What we saw

• About 190 accounts on one server had zimbraCOSId set to three COS ids that no longer existed (carbonio prov gac listed only default and defaultExternal; no domain default COS).
• carbonio prov mc default zimbraFeatureMailSendLaterEnabled TRUE, then:
  • carbonio prov -l ga user@example.com zimbraFeatureMailSendLaterEnabled returns TRUE (LDAP, falls back to default)
  • carbonio prov ga user@example.com zimbraFeatureMailSendLaterEnabled returns FALSE (mailbox service)
  • carbonio prov fc -a cos did not change the second result.
• carbonio prov mc <dangling-cos-id> ... gives ERROR: account.NO_SUCH_COS.
• Only carbonio prov fc account made the mailbox service return TRUE. Accounts that were not in the cache already returned TRUE.

Expected: either deleting a COS that accounts still reference is refused (or the accounts are moved to the domain/global default), or the mailbox service resolves a missing COS the same way as the LDAP lookup and a COS change/flush reaches it.

Steps to reproduce

1. Create COS tmp, assign it to an account, log in to that account (so it is cached).
2. Delete COS tmp (the account keeps zimbraCOSId = the deleted id).
3. Change an attribute on default, e.g. zimbraFeatureMailSendLaterEnabled TRUE, and prov fc -a cos.
4. Compare prov -l ga <account> <attr> with prov ga <account> <attr>.

Environment: Carbonio CE 25.x (4.25.2_ZEXTRAS_202603), Ubuntu 24.04, single server, 307 mailboxes. How the COSes came to be deleted is not known (older admin action).

Also filed on GitHub: https://github.com/zextras/carbonio-mailbox/issues/1172

SoapServlet returns every SOAP fault with HTTP status 422 (SC_UNPROCESSABLE_CONTENT; carbonio-mailbox store/src/main/java/com/zimbra/soap/SoapServlet.java, line 360: soapProto.hasFault(envelope) ? SC_UNPROCESSABLE_CONTENT : HttpServletResponse.SC_OK).

The SOAP 1.2 HTTP binding (W3C SOAP 1.2 Part 2, section 7.4.1.2.1) specifies 500 for faults with an env:Receiver code and 400 for env:Sender; SOAP 1.1 uses 500 for all faults. Zimbra returns 500, so SOAP clients built against that behaviour (Zimbra Desktop, the zclient / SoapHttpTransport client in zm-common, scripts) only parse the fault body on 500 and treat 422 as a transport error. The real fault code is lost: a wrong password surfaces as "HTTP 422 Unprocessable Entity" instead of account.AUTH_FAILED, mail.NO_SUCH_MSG is not recognised, and client fallbacks keyed on fault codes never run.

Steps to reproduce

curl -s -o /dev/null -w '%{http_code}\n' -H 'Content-Type: application/soap+xml' \
  --data '<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><AuthRequest xmlns="urn:zimbraAccount"><account by="name">user@example.com</account><password>wrong</password></AuthRequest></soap:Body></soap:Envelope>' \
  https://<carbonio-host>/service/soap/

Expected: 500 (env:Receiver) or 400 (env:Sender, as here), with the fault in the body, as in Zimbra and the SOAP 1.2 HTTP binding.
Actual: 422, with the fault in the body.

Environment: Carbonio CE 25.x (4.25.2_ZEXTRAS_202603), Ubuntu 24.04. Found while maintaining a community build of Zimbra Desktop 7.3.1 against Carbonio, which had to add 422 handling to its SOAP transport to read faults at all.

Also filed on GitHub: https://github.com/zextras/carbonio-mailbox/issues/1171

SoapServlet returns every SOAP fault with HTTP status 422 (SC_UNPROCESSABLE_CONTENT; carbonio-mailbox store/src/main/java/com/zimbra/soap/SoapServlet.java, line 360: soapProto.hasFault(envelope) ? SC_UNPROCESSABLE_CONTENT : HttpServletResponse.SC_OK).

The SOAP 1.2 HTTP binding (W3C SOAP 1.2 Part 2, section 7.4.1.2.1) specifies 500 for faults with an env:Receiver code and 400 for env:Sender; SOAP 1.1 uses 500 for all faults. Zimbra returns 500, so SOAP clients built against that behaviour (Zimbra Desktop, the zclient / SoapHttpTransport client in zm-common, scripts) only parse the fault body on 500 and treat 422 as a transport error. The real fault code is lost: a wrong password surfaces as "HTTP 422 Unprocessable Entity" instead of account.AUTH_FAILED, mail.NO_SUCH_MSG is not recognised, and client fallbacks keyed on fault codes never run.

Steps to reproduce

curl -s -o /dev/null -w '%{http_code}\n' -H 'Content-Type: application/soap+xml' \
  --data '<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><AuthRequest xmlns="urn:zimbraAccount"><account by="name">user@example.com</account><password>wrong</password></AuthRequest></soap:Body></soap:Envelope>' \
  https://<carbonio-host>/service/soap/

Expected: 500 (env:Receiver) or 400 (env:Sender, as here), with the fault in the body, as in Zimbra and the SOAP 1.2 HTTP binding.
Actual: 422, with the fault in the body.

Environment: Carbonio CE 25.x (4.25.2_ZEXTRAS_202603), Ubuntu 24.04. Found while maintaining a community build of Zimbra Desktop 7.3.1 against Carbonio, which had to add 422 handling to its SOAP transport to read faults at all.

Also filed on GitHub: https://github.com/zextras/carbonio-mailbox/issues/1171

I successfully installed the Zextras software, and everything worked perfectly until I configured the certificate for the mail server. After the configuration, the page failed to load, and the following services did not start:

- carbonio-files
- carbonio-tasks
- carbonio-ws-collaboration
- carbonio-message-dispatcher-auth

After extensively searching through the log files, I discovered that the issue was related to the PostgreSQL configuration. Specifically, the "Catalog Address" was listening only on the 127.0.0.1 address. Once I expanded this—adding my own private/public address—it worked perfectly.

Solution with IP address example:

# postgresql.conf
listen_addresses = 'localhost,192.168.123.4'

# pg_hba.conf
host all all 127.0.0.1/32 scram-sha-256
host all all 192.168.123.4/32 scram-sha-256

sudo systemctl restart postgresql

OS: Ubuntu Server 24.04 LTS

Zextras: Carbonio Release 26.6.2 (CE)

I hope this has helped the developers with their work. :-)

Regadrs: DrCyberg

--- old/state.py	2026-09-30 18:19:24.755097970 +0200
+++ new/state.py	2026-09-30 18:43:46.817291049 +0200
@@ -619,7 +619,8 @@
 				try:
 					rc = c.execute("%s='%s'" % (postconf, val))
 				except Exception, e:
-					return rc
+					Log.logMsg(1, "Postconf error (%s) on command %s='%s'" % (e,postconf, val))
+					return 1
 			self.clearPostconf()
 			return rc
 		return 0
@@ -631,7 +632,8 @@
 				try:
 					rc = c.execute("%s" % postconfd)
 				except Exception, e:
-					return rc
+					Log.logMsg(1, "Postconfd error (%s) on command '%s'" % (e, postconfd))
+					return 1
 			self.clearPostconfd()
 			return rc
 		return 0

But after you fix this, the next error is: Postconf error ('ascii' codec can't decode byte 0xc2 in position 16: ordinal not in range(128))

This is caused by the execution of postconf in a UTF-8 environment. The fix is to add the following lines to the file /etc/systemd/system/carbonio-appserver.target.wants/carbonio-configd.service:

...
Environment="LC_ALL=C"
Environment="LANG=C"
...

--- old/state.py	2026-09-30 18:19:24.755097970 +0200
+++ new/state.py	2026-09-30 18:43:46.817291049 +0200
@@ -619,7 +619,8 @@
 				try:
 					rc = c.execute("%s='%s'" % (postconf, val))
 				except Exception, e:
-					return rc
+					Log.logMsg(1, "Postconf error (%s) on command %s='%s'" % (e,postconf, val))
+					return 1
 			self.clearPostconf()
 			return rc
 		return 0
@@ -631,7 +632,8 @@
 				try:
 					rc = c.execute("%s" % postconfd)
 				except Exception, e:
-					return rc
+					Log.logMsg(1, "Postconfd error (%s) on command '%s'" % (e, postconfd))
+					return 1
 			self.clearPostconfd()
 			return rc
 		return 0

But after you fix this, the next error is: Postconf error ('ascii' codec can't decode byte 0xc2 in position 16: ordinal not in range(128))

This is caused by the execution of postconf in a UTF-8 environment. The fix is to add the following lines to the file /etc/systemd/system/carbonio-appserver.target.wants/carbonio-configd.service:

...
Environment="LC_ALL=C"
Environment="LANG=C"
...

So I'm happily coming along on my Zimbra-OSE/RHEL 8 to Carbonia-CE/Ubuntu 24 however on just a few accounts, imapsync is not providing enough fidelity so I'd like to import a generated tgz file from my Zimbra install.

My command as the zextras user;

zmmailbox -z -m foo@bar.com postRestURL "/?fmt=tgz&resolve=skip" /tmp/foo-2026-09-25-192213.tgz

And I get the error;

ERROR: zclient.IO_ERROR (Read timed out) (cause: java.net.SocketTimeoutException Read timed out)

I've allowed (temporarily) Carbonio to work on port 80 as well as 443 for this exorcise.  I've already done a imapsync on user foo not really expecting that to be an issue.  But would like to import the tgz file for greater fidelity.

Thanks!

1) Install a clean and matching version (same as what's on my RHEL) of Carbonio-CE on Ubuntu, either Ubuntu 22 or 24 but probably 22 as it might be more battle hardened.  I'm open to thoughts on this.

2) Stop the various Zextras/Carbonio-CE services.

3) Rename the clean install; /opt/zextras to /opt/zextras.ORG as an example.

4) Rsync /opt/zextras from the RHEL server over to the Ubuntu server.

5) Rerun the installer on Ubuntu.

Is my procedure flawed or missing anything?