6.4 国际化之多语言

史, 昂 • 2024年5月23日 am8:11 • Oinone 7天入门到精通 • 阅读 1685

多语言是国际化中大家最常面对的问题，我们需要对应用的页面结构元素进行翻译，也需要对系统内容进行翻译比如：菜单、数据字典等，甚至还会业务数据进行翻译。但不管什么翻译需求，我们在实现上基本可以归类为前端翻译和后端翻译。前端翻译顾名思义是在前端根据用户选择语言对内容进行翻译，反之就是后端翻译。本文会带着大家了解oinone的前端翻译与后端翻译

准备工作

pamirs-demo-boot的pom文件中引入pamirs-translate包依赖

<dependency>
    <groupId>pro.shushi.pamirs.core</groupId>
    <artifactId>pamirs-translate</artifactId>
</dependency>

pamirs-demo-boot的application-dev.yml文件中增加配置pamirs.boot.modules增加translate，即在启动模块中增加translate模块

pamirs:
    boot:
    modules:
        - translate

后端翻译（使用）

这里通过对菜单的翻译来带大家了解翻译模块

Step1 新增翻译记录

切换应用到translate模块，点击新增翻译。

选择新增翻译生效模块
选择翻译的模型为：菜单模型
源语言选择中文，目标选择English
添加翻译项目：
1. 源术语为：商店
2. 翻译值为：shop
3. 状态为：激活

Step2 查看效果

应用切换到Demo模块，在右上角切换语言至英语

后端翻译（自定义模型的翻译）

在前面菜单的翻译中，似乎我们什么都没做就可以正常通过翻译模块完成多语言的切换了。是不是真如我们想象的一样，当然不是。是因为Menu模型的displayName字段加上@Field(translate = true)注解。

Step1 为PetType模型的name字段增加翻译注解

package pro.shushi.pamirs.demo.api.model;

import pro.shushi.pamirs.meta.annotation.Field;
import pro.shushi.pamirs.meta.annotation.Model;
import pro.shushi.pamirs.meta.base.IdModel;

@Model.MultiTable(typeField = "kind")
@Model.model(PetType.MODEL_MODEL)
@Model(displayName="品种",labelFields = {"name"})
public class PetType extends IdModel {

    public static final String MODEL_MODEL="demo.PetType";

    @Field(displayName = "品种名" , translate = true)
    private String name;

    @Field(displayName = "宠物分类")
    private String kind;
}

Step2 重启应用查看效果

切换应用到translate模块，点击新增翻译

切换应用到Demo模块，切换中英文，查看效果

前端翻译

还记得我们前端第一个自定义动作吗？会弹出“oinone第一个自定义Action，啥也没干”，我们要对它进行翻译。

Step1 修改前端DoNothingActionWidget.ts

import translateValueByKey
提示语用translateValueByKey加上翻译 const confirmRs = executeConfirm(translateValueByKey(\'oinone第一个自定义Action，啥也没干\')||\'oinone第一个自定义Action，啥也没干\');

前端更多翻译工具请见前端高级特性-框架之翻译工具

import {
  Action,
  ActionContextType,
  ActionWidget,
  executeConfirm,
  IClientAction,
  SPI,
  ViewType,
  Widget,
  translateValueByKey
} from '@kunlun/dependencies';

@SPI.ClassFactory(ActionWidget.Token({ name: 'demo.doNothing' }))
export class DoNothingActionWidget extends ActionWidget {
  @Widget.Method()
  public async clickAction() {
        const confirmRs =  executeConfirm(translateValueByKey('oinone第一个自定义Action，啥也没干')||'oinone第一个自定义Action，啥也没干');
    }
}

//定义动作元数据
Action.registerAction('*', {
  displayName: '啥也没干',
  name: 'demo.doNothing',
  id: 'demo.doNothing',
  contextType: ActionContextType.ContextFree,
  bindingType: [ViewType.Table]
} as IClientAction);

Step2 新增翻译记录

前端翻译的翻译记录对应的模型可以随意找一个放。但要注意几点：

不要找有字读配置translate = true的模型，因为会影响后端翻译性能。
最好统一到一个模型中，便于后续管理。这里大家可以自定义一个无有业务访问且本身无需要翻译的模型来挂载，避免性能损失

Step3 刷新远程资源生成前端语言文件

Step4 新增或修改.env

前端在项目根目录下新增或修改.env，可以参考.env.example文件。通过.env文件为前端配置oss文件路径，针对I18N_OSS_URL配置项。真实前端访问翻译语言文件的路径规则为：http://bucket.downloadUrl/mainDir/租户/translate/模块/语言文件。

yaml文件中oss配置的文件路径：http://pamirs.oss-cn-hangzhou.aliyuncs.com/upload/demo/
租户/translate/模块/语言文件前端会自动根据上下文组织

# 后端api配置
# API_BASE_URL=http://127.0.0.1:8090
# 下面是国际化语言的cdn配置，默认用当前请求链接下的路径: /pamirs/translate/${module}/i18n_${lang}.js
I18N_OSS_URL=http://pamirs.oss-cn-hangzhou.aliyuncs.com/upload/demo

Step5 重启前端应用看效果

对语言进行中英文切换，进入宠狗达人页面，点击【第一个自定义Action】，查看前端翻译效果

Oinone社区作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9328.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Oinone 7天从入门到精通

史, 昂数式管理员

0 2

6.5 权限体系（改）

上一篇 2024年5月23日 am8:10

6.3 数据审计（改）

下一篇 2024年5月23日 am8:12

Oinone 7天入门到精通

4.1.14 Search之非存储字段条件

search默认查询的是模型的queryPage函数，但我们有时候需要替换调用的函数，这个特性会在下个版本支持。其核心场景为当搜索条件中有非存储字段，如果直接用queryPage函数的rsql拼接就会报错，所以非存储字段不会增加在rsql中。本文介绍一个比较友好的临时替代方案。非存储字段条件（举例） Step1 为PetTalent新增一个非存储字段unStore @Field(displayName = "非存储字段测试",store = NullableBoolEnum.FALSE) private String unStore; 图4-1-14-1 为PetTalent新增一个非存储字段unStore Step2 修改PetTalent的Table视图的Template 在标签内增加一个查询条件 <field data="unStore" /> 图4-1-14-2 修改PetTalent的Table视图的Template Step3 重启看效果进入宠物达人列表页，在搜索框【非存储字段测试】输入查询内容，点击搜索跟无条件一致 Step4 修改PetTalentAction的queryPage方法 package pro.shushi.pamirs.demo.core.action; …… 引入依赖类 @Model.model(PetTalent.MODEL_MODEL) @Component public class PetTalentAction { ……其他代码 @Function.Advanced(type= FunctionTypeEnum.QUERY) @Function.fun(FunctionConstants.queryPage) @Function(openLevel = {FunctionOpenEnum.API}) public Pagination<PetTalent> queryPage(Pagination<PetTalent> page, IWrapper<PetTalent> queryWrapper){ QueryWrapper<PetTalent> queryWrapper1 = (QueryWrapper<PetTalent>) queryWrapper; Map<String, Object> queryData = queryWrapper.getQueryData(); String unStore = (String) queryData.get(LambdaUtil.fetchFieldName(PetTalent::getUnStore)); if (StringUtils.isNotEmpty(unStore)) { //转换查询条件 queryWrapper1.like( 图4-1-14-3 修改PetTalentAction的queryPage方法 Step5 重启看效果在搜索框【非存储字段测试】输入查询内容，跟通过【达人】字段搜索的效果是一致的图4-1-14-4 示例效果

史, 昂
2024年5月23日
1.2K000
Oinone 7天入门到精通

2.2 互联网架构作为最佳实践为何失效

如果把互联网架构比作社会主义，Oinone就是也要做有中国特色的社会主义，才能符合国情。随着业务和生态的发展，企业对效率、性能、体验和智能化等方面的要求越来越高，但很多企业的系统面临着严重的系统架构落后和系统间割裂等问题，这些问题导致原有系统在业务发展下面临着效率和性能的双重挑战。与此同时，互联网平台的技术水平远远领先于传统企业系统，但是是否可以直接将互联网架构照搬到企业数字化转型中呢？显然，这是不合适的，因为互联网架构在企业数字化转型中面临着许多水土不服的问题。本章节将结合互联网中台架构的发展，分析这些问题的原因。借鉴互联网中台理念我们要先看互联网架构的发展，是如何一步步到今天提的中台架构概念的，每一步又解决了什么具体问题，我们以阿里架构变迁史为例来看下（如下图2-2所示）：图2-2 阿里架构变迁史在2009年，淘宝上线了五彩石项目，这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么，淘宝为什么要开发五彩石项目呢？因为当时淘宝面临两个非常严峻的问题，一个是性能问题，数据库连接不足，数据库成为了瓶颈；另一个是效率问题，当时淘宝有百余个研发人员，但核心系统只有一套测试、预发、线上环境，导致研发需求排队等待。在开始五彩石项目之前，淘宝还做了千岛湖项目，用来验证服务化架构的可行性，将用户中心独立出来。随后，淘宝开启了五彩石项目，目标是通过增加人力来提升效率，通过增加机器来提升性能。随着淘宝的业务发展，他们又面临了一个问题：各个服务之间有很多重复的建设，效率低下。为了解决这个问题，淘宝开始从服务化转向平台化，并创立了“共享业务事业部”，将重复建设的公共业务分配给这个事业部，以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。但是随着业务的快速发展，淘宝变成了一个拥有几十个事业部的巨型企业，而这带来了新的问题：效率问题。例如，如果需要在一个业务线上做出改动，需要与十几个平台进行沟通，这是非常低效的。同时，对于一个平台来说，需要面对来自不同事业部的需求，这需要平台研发人员具备理解和抽象所有业务线需求的能力，这让平台研发人员感觉回到了单体应用时代，所有的需求都要排队，即使增加人力也无法提高效率。这个问题主要表现在交易平台上。为了解决这个问题，淘宝提出了中台的概念，中台是在一套规范下建立的，让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性，提供通用能力。简而言之，就是将“共享业务”中的“业务”两个字去掉，只提供通用能力的平台我们将每个阶段的核心目标总结为一句话：从单体到服务：通过增加人员和机器来提高效率和性能；从服务化到平台化：解决服务化阶段因缺乏规划而导致的重复建设问题；平台化到中台化：在一套规范下，让各业务团队自行决定业务系统发展，适用于多个业务线或多个场景应用的独立发展。类似地，在企业数字化转型过程中，也面临着类似的问题：随着企业业务在线化，对系统性能和稳定性提出了更高的要求，但由于内部系统之间的割裂，导致很多重复建设。因此，我们需要进行服务化和平台化；没有一个供应商能够解决企业所有的商业场景问题，所以需要多个供应商共同参与。我们可以将供应商类比为各业务线，在一套规范下让供应商或业务线自行决定业务系统的发展。然而，阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式，即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式，对企业来说历史包袱较大。在企业中，让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂，再加上共建会导致企业架构的负载过重，这对企业来说就不再是赋能，而是“内耗”。互联网中台架构在企业实践中遇到的问题在1.3《Oinone的生态思考》一文中，《与中台的渊源》部分提到，在阿里云为企业提供数字化项目时，客户经常会对以下三个问题提出质疑，这些问题非常突出： 1我们听说你们具备敏捷响应能力，但为什么改动需求如此缓慢？不仅所需时间更长，而且成本更高？ 2我们听说你们有能力中心，但为什么当我们引入新供应商或开发新场景时，前期建立的能力中心无法支持我们？ 3我们听说你们的性能很好，但为什么我们需要投入更多的物理资源来支持项目？在探讨互联网架构的适用性时，我想提出以下两个问题： 1企业应用程序的性能问题是否与互联网平台公司遇到的性能问题相同？ 2企业应用程序的开发效率问题是否与互联网平台公司遇到的效率问题相同？通过比较企业和互联网之间的差异，我们可以了解水土不服的核心原因。企业互联网企业IT组织能力无法与数字化转型的速度匹配，缺乏足够的人才支持。为了提高开发效率，企业需要寻找工具和技术来降低开发难度，同时提高个人开发效率互联网企业拥有众多优秀的人才，需要解决团队协作和知识共享的问题，即协同开发的效率。企业无法制定并主导技术规范，这导致了能力复用的不足。为了提高效率和减少开发成本，企业需要建立统一的技术规范和标准，以便能力复用和组织协同。互联网企业可以自定义技术规范，因此能力复用更易于保障。企业往往当前业务量相对小，期望数字化建设能打动业务发展，对业务发展的预期比较高，所以企业的诉求是即满足当下成本效应又能兼顾未来对发展预期互联网企业起步时的系统目标负载就高，通常会忽略资源起步门槛的问题，当然也可以通过自动扩容、云计算等方式来解决初期的负载问题。表2-1从企业与互联网的对比，看水土不服的核心原因我们可以看到企业和互联网架构在很多方面存在着不同的需求和问题。因此，在提供数字化服务时，Oinone需要注意与企业的组织能力进行匹配，并根据企业自身的特性来提供在线化的服务能力。这就像在社会主义制度下需要有中国特色一样，Oinone也需要有适合中国企业的特色。

史, 昂
2024年5月23日
1.4K000
Oinone 7天入门到精通

第7章 Oinone的设计器们（改）

史, 昂
2024年5月23日
1.6K001
Oinone 7天入门到精通

业务域

1. 业务域介绍业务域是根据业务域对集成应用、开放接口进行归类管理。在创建集成应用、开发接口时，可选择归属的业务域。操作入口：集成设计器——业务域。 2. 业务域管理业务域管理提供新增、删除、搜索操作。 2.1 业务域列表支持按照编码、名称、描述搜索业务域。 2.2 新增业务域新增业务域：输入业务域名称、描述新增。 2.3 删除业务域当前业务域未被其他数据记录引用时，可删除成功，反之如果被引用了，不允许删除。

史, 昂
2024年6月20日
1.6K000
Oinone 7天入门到精通

第4章 Oinone的高级特性

史, 昂
2024年5月23日
1.4K000

登录后才能评论

评论列表（2条）

xiao3 2024年11月25日 am10:43

只支持英语吗？如何添加其他语种？

Reply
- shao 2024年11月25日 pm5:24
  
  @xiao3：支持其他的国家的语言，需要在资源里面创建，如果有其他的疑问，也可以群内联系我们哈
  
  Reply