ERP中要實現界面多語言的功能，則要對各種情況的字符串進行處理并作出翻譯。有些字符串的翻譯是有規律可行的，遵循相應的模板模式，解析字符串，可以實現機器翻譯的效果。

請看帳套數據庫表的設計ADCOMP

CREATE TABLE dbo.ADCOMP(RECNUM DECIMAL (28) IDENTITY NOT NULL,COMPANY_CODE NVARCHAR (10) CONSTRAINT DF__ADCOMP__COMPANY___0E391C95 DEFAULT ('') NOT NULL,COMPANY_NAME NVARCHAR (50) CONSTRAINT DF__ADCOMP__COMPANY___0F2D40CE DEFAULT ('') NOT NULL,SUSPENDED NVARCHAR (1) NULL,DB_SERVER NVARCHAR (128) NULL,DB_DATABASE NVARCHAR (128) NULL,DB_USER NVARCHAR (128) NULL,DB_PASSWORD NVARCHAR (128) NULL,DB_DRIVER NVARCHAR (20) NULL,DB_REPT_DRIVER NVARCHAR (20) NULL,CREATED_DATE DATETIME NULL,CREATED_BY NVARCHAR (10) NULL,REVISED_DATE DATETIME NULL,REVISED_BY NVARCHAR (10) NULL) ?

在界面上，它的實現方法，如下圖所示

數據表ADCOMP的COMPANY_CODE在界面上翻譯成Company Code，字段COMPANY_NAME翻譯成Company Name，這種翻譯方法有規律可遵循，可以實現由程序自動翻譯。

下面列舉幾種常見的情況，分析如何實現程序解析并翻譯。

模式1? 下劃線分割單詞? COMPANY_CODE

這種模式的特點是有含義的單詞，全部以下劃線分隔，有含義的單詞可以是英語中的名詞，也可以是自造的縮寫，詞與詞之間用下劃線分隔。下面再舉幾個例子分析

ITEM_NO –> Item No 物料編號, NO是Number的縮小

ITEM_CODE –> Item Code 物料編碼

MAIN_LOC –> Main Loc 物料主檔中的設定物料的主倉庫

FG_LOC –>? Fg Loc 車間控制中的參數，設定完工成品默認進倉的倉庫 FG是對成品Finished Good的縮寫

處理算法：先去掉下劃線，以空白符號隔開，再把首字母大小，其余字母小寫

?

模式2?? 多余的前綴去除 tbl_User

我一直覺得，這種命名方法有待于商議，給數據庫對象加前綴。比如給所有的表加tbl,所有的視圖加vw-，存儲過程加sp_, 觸發器加tr_，這樣，形成了一套很有規律的數據庫命名方案。

tbl_User? 用戶數據庫??? sp_ItemNoWhereUsed 存儲過程，查詢物料編號在哪些物料清單中用到

vw_User? 用戶視圖????? tr_UserNew? 當增加新用戶時，自動寫入創建當前的用戶的時間和IP地址

這種方法好處理，去掉固定的前綴即可。tbl_User變成User，然后可以自動翻譯成用戶。

這也產生了一個問題，經過去除前綴處理，上面有2個數據庫對象均是User(tbl_Ueer,vw_User) ，這2個最終都被翻譯成了User,在有些場合，這會造成語意不明。舉例說明

Style 在服裝生產行業，常用來指款式。一套衣服，有2個系列，3種款式，4種顏色，這樣生產一個系列的衣服，就會產生2*3*4=24，一共有24件衣服。

在程序中，為了讓窗體看起來美觀，經常加一些漂亮的皮膚，比如Office 2007的藍色，Office 2010的銀色，形容程序的外觀，也是用的Style這個詞。

于是，同一個詞語有2個地方用到，但是它們的含義完全不同。爭對這種情況，為了實現翻譯自動化，我的處理方法是把后一種情況(界面外觀)的用詞改成Application Style，這樣可以與前一種衣服的Style區分開來。

?

模式3? 程序類型定義，數據庫表對應的內存對象 UserEntity

LLBL Gen 會給生成的表加上Entity后綴，以表示它是數據庫的內存對象表示，這樣，我們自己給對象定義名稱時，繞開這個規定，避免給對象名加Entity后綴。

這個界面，是采用翻譯自動化實現的。Source Table Name是數據庫中的表定義，比如UserGroup表的定義如下

CREATE TABLE dbo.UserGroup(UserGroup NVARCHAR (10) DEFAULT ('') NOT NULL,Description NVARCHAR (30) DEFAULT ('') NOT NULL,Suspended NVARCHAR (1) NULL,CreatedDate DATETIME NULL,CreatedBy NVARCHAR (10) NULL,RevisedDate DATETIME NULL,RevisedBy NVARCHAR (10) NULL,OwnerBranch NVARCHAR (4) NULL,SourchBranch NVARCHAR (4) NULL,Email NVARCHAR (100) NULL,CONSTRAINT PK_UserGroup PRIMARY KEY (UserGroup)) GO

定義表之后，借助于實體生成工具，或是LLBL Gen代碼生成器，生成了實體對象UserGroupEntity。

我取數據表名時，只需要把Entity去掉，就可以知道這個實體對象對應的表名。Table Name這一列是方便于閱讀的，根據表的定義自動生成，沒有實際的存儲在數據庫。

?

4? 數據表關系，實體對象關系(一對一，一對多)的命名 BranchDetails

這個靈感來源于LLBL Gen Pro的設計器配置屬性，請看下圖

這幾個部分節專門是設置命名規則的，Strip patterns剔除模式，Name pattern命名方法。

來看看關系的命名，文檔中是這樣寫的

{$StartEntityName} for the name of the start entity, {$EndEntityName} for the name of the end entity, $P or $S suffix to entity name macros to pluralize or singularize them

singularize ['si?gjul?raiz]

vt. 使顯著, 使成為唯一, 使成為單數

pluralize ['plu?r?laiz]

vt. 使成復數

vi. 兼職, 成復數形式

$P 復數表達形式，比如下圖中的BranchDetail在關系中表示成了復數形式BranchDetails， 這是默認的生成方法，不源于這里的設置，也可以修改。

?

這其實也解釋了系統中，實現一種通用的命名方案的好處，統一的命名方案，有利于界面翻譯處理，也可以讓程序望文生義，簡單直觀。

轉載于:https://www.cnblogs.com/JamesLi2015/archive/2013/05/17/3083148.html

總結

以上是生活随笔為你收集整理的ERP开发中应用字符串解析实现界面翻译智能化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。