Add CMakeL10n rules #1

已合併
SlavekB 5 年之前 將 1 次代碼提交從 feat/CMakeL10n 合併至 master
所有者

KVIrc is in many ways different from the usual TDE applications. Therefore, I am not surprised that even for translations it is significantly different.

While usual TDE applications translate a string or a context + string, the string + context is used here. Yes, the opposite order of arguments. Moreover, the context is not actually used as a translation context, but it determines the catalog in which the translation is to be searched.

As a result, old modified kde-xgettext can not be used to extract strings for translation. Therefore, there is a forced use of standard xgettext, instead of kde-xgettext. At this moment, I do not think of a more viable solution.

Some objections? Some ideas?

KVIrc is in many ways different from the usual TDE applications. Therefore, I am not surprised that even for translations it is significantly different. While usual TDE applications translate a string or a context + string, the string + context is used here. Yes, the opposite order of arguments. Moreover, the context is not actually used as a translation context, but it determines the catalog in which the translation is to be searched. As a result, old modified kde-xgettext can not be used to extract strings for translation. Therefore, there is a forced use of standard xgettext, instead of kde-xgettext. At this moment, I do not think of a more viable solution. Some objections? Some ideas?
SlavekB added the PR/rfc label 5 年之前
所有者

Looks ok to me

Looks ok to me
SlavekB removed the PR/rfc label 5 年之前
SlavekB closed this pull request 5 年之前
SlavekB 刪除分支 feat/CMakeL10n 5 年之前
SlavekB 新增至R14.0.6 release 里程碑 5 年之前
The pull request has been merged as 0fbed184da.
登入 才能加入這對話。
No reviewers
未選擇里程碑
No Assignees
2 參與者
訊息
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/kvirc#1
Loading…
尚未有任何內容