「Tolgee」協助您開發多語系APP

「Tolgee」是一款新興的翻譯輔助系統,可以協助您開發多語系APP。

目前最有名的雲端翻譯網站為 crowdin,功能強大的付費系統,很推薦使用;若公司需要自行架設(self-hosted),可以參考weblatetolgee,這兩樣都是較有名的免費開源翻譯系統。

以下是 WeblateTolgee 的比較表,以幫助你選擇適合的翻譯與本地化平台:

特性WeblateTolgee
類型自託管 + 雲端自託管 + 雲端
開源✅(完全開源)✅(開源,但部分功能需付費)
托管方式自託管 / Weblate 服務自託管 / Tolgee Cloud
即時協作
支援的格式40+ 種格式(JSON、YAML、PO、XLIFF、TS、ResX 等)JSON、XLIFF、PO、YAML、TS、Java Properties 等
機器翻譯支援 Google、DeepL、Azure、Apertium支援 Google、DeepL、Azure
翻譯記憶庫(TM)
自動提議翻譯
語言品質檢查✅(內建 QA 機制)✅(內建錯誤檢查)
上下文支援🟡(需手動提供)✅(可透過 Tolgee SDK 自動擷取)
API & SDKREST API,可與 Git、CI/CD 整合REST API,專有 SDK(適用於 React、Vue、Angular 等)
Git 整合✅(自動同步)✅(自動同步)
視覺化翻譯(In-context)🟡(有限支援)✅(內建即時預覽)
權限管理✅(細緻的角色與權限控制)✅(細緻的角色與權限控制)
價格免費(自託管)/ 付費雲端免費(基本功能)/ 進階功能需付費
適合對象開發團隊、開源專案、企業需要即時翻譯預覽的開發團隊

實作總結(推薦使用tolgee)

  • Weblate 需先選定APP翻譯格式,然後再進行翻譯,這樣可以直接與APP版控整合,但跨平台APP需要重複翻譯多次(多個格式),另外weblate本身語言翻譯很差(乾脆不要提供各國語系版),寧願使用英文版。
  • Tolgee 則採先翻譯方式,然後再整合不同APP開發格式輸出,這樣只要翻譯一次即可,再匯出讓工程師使用,但無法整合git較不方便。

ps. 到本日(2025/3/22) weblate尚未支援apple string catalog翻譯檔案(.xcstrings),很不方便;而tolgee 3/5之後支援了。

Android自動調整文字大小

我是個半吊子Android程式師,有時候常常被使用者罵文字版面跑掉,深深覺得andoird要能自動調整textview文字大小非常重要。

有些android使用者會調整手機預設字型大小,有些因為手機本身解析度不同,甚至摺疊手機,都會影響APP使用體驗;因此我們設計app一定要考慮文字大小。

官網已經有詳細的介紹,請點選這裡參考

我自己則常用以下設定來解決文字大小問題。

android:autoSizeTextType="uniform"
android:autoSizeMinTextSize="20sp"
android:autoSizeMaxTextSize="24sp"
android:autoSizeStepGranularity="2sp"

postgres 指令(連線、安裝)

我實在太弱了,不太會用postgres,每次要連線到openproject、teedy都要想很久。

# -U 帳號
# -d 資料庫名稱
# -p 埠(預設5432)
# -h 主機
# -W 需要輸入密碼
psql -U root -d openproject -p 5432 -h localhost -W

docker 安裝postgres

docker run -d --name postgres-17 -p 5432:5432 -e POSTGRES_USER=root -e POSTGRES_PASSWORD=ilovekafeiou -v  postgres-17-data:/var/lib/postgresql/data postgres:17.4-bookworm 

常用指令

# 連到資料庫
\c 資料庫名稱

# 顯示所有table
\dt

讓Content-Disposition解決非英文檔案,下載亂碼問題

這是老問題了,很多老外都忽略這個,我在協助teedy翻譯時,發現下載中文檔案中文會出現空白,看一下程式原來是忘了進行編碼導致,就順手提交一下解法。

#以下為java虛擬碼
CONTENT_DISPOSITION, "inline; filename*=utf-8''" + filenameEncode( "檔名" )

private String filenameEncode(String name) {
try {
return java.net.URLEncoder.encode(name, "UTF-8").replace("+", "%20");
} catch (java.io.UnsupportedEncodingException e) {
e.printStackTrace();
return name;
}
}

參考 :

又是windows 11,停用TLS 1.0、TLS 1.1,只支援1.2

windows 11 從2024年開始,預設就停用TLS 1.0、TLS 1.1了。

表姊公司dovecot 內送郵件伺服器沒有支援TLS 1.2,解法就兩種

  1. 啟用windows 11 TLS 1.0、TLS 1.1
    https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-10-11-deprecation-in-windows
  2. 讓dovecot相容TLS 1.2
    重點在Linux Server上的openssl 版本必須1.0.1或以上
    dovecot啟用TLS 1.2 做法如下:
    https://serverfault.com/questions/959186/error-performing-tls-handshake-with-dovecot-2-3-upgrade

我自己修改dovecot啟用TLS 1.2 做法如下:

  1. 產生dh.pem
    openssl dhparam 4096 > /etc/dovecot/dh.pem
  2. 修改 /etc/dovecot/conf.d/10-ssl.conf

ssl_dh =</etc/dovecot/dh.pem
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
ssl_prefer_server_ciphers = yes

最後再更新我自己整合的郵件伺服器(綁定本地端微軟網域伺服器)
https://github.com/WilliamFromTW/docker-Postfix-AD


2024/01/10 (冏只隔一天又出現其他問題)

上次問題解決之後(windows 11其實有更新到24h2),後續又發現其他台windows 11未更新24h2,收發信還是有問題,但問題不太一樣

Jan 10 09:49:02 docker dovecot: pop3-login: Disconnected: Connection closed: SSL_accept() failed: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher 

我除了更新mail server的postfix 、dovecot、openssl (RockyLinux 8.8) 外,變更dovecot一些設定,就解決問題了。

  1. 啟用windows 11 的TLS 1.0 、TLS 1.1
    依照微軟建議,我做成reg檔案,請按此下載匯入到windows啟用
  2. 更改dovecot設定,改成最小可支援 TLS 1.1 ,ssl_cipher_lis也修改(出處請參照這裡)
ssl_min_protocol = TLSv1.1
#ssl_cipher_list = ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW:!DH@STRENGTH
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

win11 22h2帶來的影響,無法連線MSSQL 2005

我表姊公司在1999年就開始使用高格EPR系統,這個系統使用當時開發windows程式的顯學 Borland 軟體架構(2-tier、3-tier),資料庫使用interbase 。

高格一路上升級,資料庫改成BDE+mssql 2005混合體,連線方式從netbeui改tcpip,用戶端作業系統從windown 98到windows 10也能使用。

我認為高格是一款很棒的軟體,不比我二姊公司現在還在使用生產力中心開發的老古董”excel 97 進銷存系統”差。

直到最近,表姊公司換新的筆電,原本依照步驟,將windows啟用.net framework 3.5、smb 1.0 ,安裝interbase、mssql 2005 client 就可以連到 mssql 2005 server,實際上安裝後,卻無法正常連線到資料庫;我找了很久找不出原因,只好google一下”win11 mssql 2005″,居然在ITHOME找到解法 https://ithelp.ithome.com.tw/questions/10212352(感謝 aaron3399mihihi) ,只要利用 IISCrypto 這個軟體(備用下載),將win11被移除的加密方式加回來,就可以連上mssql 2005 server了,也讓高格能繼續生存下去。

加回來的加密協定:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_3DES_EDE_CBC_SHA

國外參考

老派java+eclipse+sprint boot遇到3DES加密問題

API,傳資料只用簡單的3DES加解密,但是java 預設只有3DES的PKCS5Padding,要達到PKCS7Padding(windows c# 只支援PKCS7Padding),就只能請Bouncy Castle幫忙,我使用bcprov-jdk15to18-1.78.1.jar、jdk17。

程式改寫大概如下:

// java 只有padding5,用bouncycastle,改寫成可使用padding7
static {
if(Security.getProvider("BC")!=null) Security.removeProvider("BC");
Security.addProvider(new BouncyCastleProvider());
}


// 使用CBC、PKCS7Padding
原本寫法
Cipher decryptCipher = Cipher.getInstance("DESede/CBC/PKCS5Padding");
改成
Cipher decryptCipher = Cipher.getInstance("DESede/CBC/PKCS7Padding","BC");

在Eclipse開發時很正常,正式執行時,出現以下錯誤:

jce cannot authenticate the provider bc

我查了一下原來jdk 17是17.0.9版,這問題於jdk 17.0.10(2024年1月)解決,就這麼剛好只差一版;最後,我升級至目前最新 jdk17.0.12版就解決了。參考來源


另外 windows uwp c#寫法也幾乎一至,因java是API,windows app為client,所以也就順手了解一下

public static String Encrypt3DesCbcPKCS7Padding(String sIV,String sSecretKey, String sData)
{
TripleDES tdes = TripleDES.Create();
IvParameterSpec ivSpec = new IvParameterSpec(System.Text.Encoding.UTF8.GetBytes(sIV));
SecretKeySpec secretKeySpec = new SecretKeySpec(System.Text.Encoding.UTF8.GetBytes(sSecretKey), "DESede");
Cipher encryptCipher = Cipher.GetInstance("DESede/CBC/PKCS7Padding", "BC");
encryptCipher.Init(Cipher.ENCRYPT_MODE, secretKeySpec, ivSpec);
return Base64.ToBase64String(encryptCipher.DoFinal(System.Text.Encoding.UTF8.GetBytes(sData)));

}
1 2 3 4 ... 60