写点什么

iOS 文本的多语言适配和实践

  • 2021-09-13
  • 本文字数:4253 字

    阅读完需:约 14 分钟

iOS文本的多语言适配和实践

背景

产品被多个国家使用,产品方希望产品拥有更好的多语言使用体验,所以设计师提供多种字体来适配指定的语言。基于以上背景,客户端需要快速给出解决方案并且上线。

字体包的多语言适配和实践

需求分析

首先,在了解产品需求和设计方案之后,结合业务研发人员的痛点,整理出以下需求。

  1. 产品和设计的需求

  • 不同语言,对应字体包不相同。

  • 全局字体默认使用设计师指定的字体包。

  • 某些语言的字体包缺少某些字重版本,要求降级使用下一个字重版本。

  • 存在某些特殊文案不使用全局字体包(例如:中文,它有专属的字体包,和语言环境无关)。

  • 产品迭代需要快速支持扩展,尽量减少研发投入成本。

设计师要求的字体包资源



  1. 研发的痛点和需求

  • 存在公用组件(其他业务线都在使用,伴鱼公共业务组件目前有 50+),不能修改通用组件。

  • 仅壳工程支持且依赖字体包。

  • 字体包资源来源方式要灵活。

总结一下,产品和设计的需求强调字体适配的全局性、多样性、可扩展性,研发关心的是解耦、职责单一、灵活性。

技术设计

分析过后,先确定技术框架的分层。


垂直分层和水平模块



如图所示分 3 层,1.基础组件提供核心实现,并支持需求扩展 2.业务组件(无相关修改)3.壳工程提供资源包和代理者。


FontPackage 组件要负责什么?

  • FontPackageManager,负责绑定代理来获取资源包,控制流程逻辑。

  • FontPackageExtension,负责 AOP,增加文本属性来满足特殊场景的多样性。

  • FontPackageModel,映射字体包资源的配置信息,明确了使用协议。上层业务可以增加和调整参数来配置字体包资源。


壳工程的资源包配置

  • env:国际编码, default 表示设计师指定的默认字体。注意有些国际编码代表一种语言,例如英语存在 en-US、en-GB 等多种编码,需要统一为 en。

  • font:字重类型,0:light、1:medium、2:bold。斜体默认替换为 medium

  • name:字体源文件的名称。例如:GothamRndSSm-Medium

备注:因为设计师只要求 3 种字重,默认 light 字重,这个和系统提供的 UIFontWeight 不太一致。

//壳工程中的配置文件,反序列化传回FontPackage层//appfont.json{    "list": [{        "env" : "vi",        "note" : "越南语,按照国际编码:vi、vi-VN。FontPackageManager 判断国际编码来对应",        "data" : [{                "font" : 0,                "name" : "genjyuu_light(越南细)"            },{                "font" : 1,                "name" : "genjyuu_medium(越南中)"            },{                "font" : 2,                "name" : "genjyuu_bold(越南粗)"            }        ]    }, {        "env" : "default",        "note" : "其他语种默认使用字体,但优先判断设备的国际编码来匹配字体包",        "data" : [{                "font" : 0,                "name" : "GothamRndSSm-Light"            },{                "font" : 1,                "name" : "GothamRndSSm-Medium"            },{                "font" : 2,                "name" : "GothamRndSSm-Bold"            }        ]    }]}
复制代码


添加字体包和配置文件,还有冷启动流程:

冷启动流程图



技术开发

FontPackage 功能组件共 3 个 Class,200+行代码。首先,在冷启动时候 FontPackage 根据 json 配置缓存语言编码匹配到的字体包资源 Model。然后使用 runtime hook UIFont 类的几个构造函数,更换构造函数的 fontName 参数。目前确定 5 个构造函数:

//已处理+ (UIFont *)systemFontOfSize:(CGFloat)fontSize;+ (UIFont *)systemFontOfSize:(CGFloat)fontSize weight:(UIFontWeight)weight;+ (UIFont *)boldSystemFontOfSize:(CGFloat)fontSize;+ (UIFont *)italicSystemFontOfSize:(CGFloat)fontSize;+ (UIFont *)fontWithName:(NSString *)fontName size:(CGFloat)fontSize;
复制代码


最后统一使用 +fontWithName:size: 函数初始化,fontName 为自定义字体包。函数 -fontpackage_name: 根据原 fontName 更换为对应的自定义字体包。


//FontPackageExtension.m //UIFont+FontPackage.m


+ (UIFont *)xxxFontPackage_systemFontOfSize:(CGFloat)fontSize weight:(UIFontWeight)weight { NSString *fontName = @""; if (weight == UIFontWeightMedium) { fontName = @"medium"; } else if (weight > UIFontWeightMedium) { fontName = @"bold"; } return [self fontWithName:fontName size:fontSize];}
+ (UIFont *)xxxFontPackage_italicSystemFontOfSize:(CGFloat)fontSize { //斜体默认是medium return [self fontWithName:@"medium" size:fontSize];}
+ (UIFont *)xxxFontPackage_boldSystemFontOfSize:(CGFloat)fontSize { return [self fontWithName:@"bold" size:fontSize];}
+ (UIFont *)xxxFontPackage_systemFontOfSize:(CGFloat)fontSize { return [self fontWithName:@"" size:fontSize];}
+ (UIFont *)xxxFontPackage_fontWithName:(NSString *)fontName size:(CGFloat)fontSize { fontName = [self fontpackage_name:fontName]; return [self xxxFontPackage_fontWithName:fontName size:fontSize];}


+ (NSString *)fontpackage_name:(NSString *)fontName { fontName = [fontName lowercaseString]; FontPackageFont replaceFont = FontPackageFontLight; //默认light if ([fontName containsString:@"medium"]) { replaceFont = FontPackageFontMedium; } else if ([fontName containsString:@"bold"]) { replaceFont = FontPackageFontBold; } //匹配替换的字体 NSString *replaceFontName = [[FontPackageManager shareInstance].fontPackageInfo.dataMap objectForKey:@(replaceFont)]; return replaceFontName;}
复制代码

文本信息的多语言适配和实践

针对海外用户做语言本地化也是一项重要的产品功能,但很多组件在开发之初并未预留本地化拓展的接口,客户端需要提供一套优雅的解决方案来应对此问题。

需求分析

1、产品和设计的需求

  • 语言本地化

  • 未提供本地化的语言,默认使用产品指定的语言

  • 快速支持新语言本地化

2、技术要求

  • 接入成本低,不需要对成熟组件做改动

  • 解耦,其他组件无需依赖本功能

技术设计

垂直分层和水平模块



如图所示分 3 层:1、基础组件提供需求扩展 2、业务组件(基本不需要修改,如有特殊属性需求可以依赖基础组件)3、壳工程提供资源包和以及资源包的更新

LocalizedString 组件要负责什么?

  • LocalizedString,负责文字本地化适配。

  • LocalizedTool,负责语言包的配置、读取、更换功能。

  • LocalizedExtension,负责 AOP,补充某些属性。

语言包目录如下:

语言包目录



可以看到,语言包是按照语言码进行命名的,方便在使用中及时定位到对应文件并读取(存在多种编码的语言,统一使用其基础类)。同时,在壳工程中会对本地语言包进行刷新,App 启动后会检查是否有新的语言包可用,如果有会保证数据同步。

配置好语言包后,接下来需要冷启动时初始化 LocalizedString 组件。启动时组件任务流程图如下:

冷启动流程图



技术开发

考虑到字符串最终都会依托于 UILabel 进行展示,[UILabel setText:]会作为设置展示文本的唯一收口。所以我们对[UILabel setText:]进行了 hook 和拓展,其内部操作流程图如下:

AOP 流程图



LocalizedString 组件有 NSString、UILabel 分类分别做了属性拓展。具体代码如下:

@interface UILabel (Localized)@property (nonatomic, assign) BOOL isAutoLocalized; ///< 设置的文字是否要自动转换成本地化的语言,默认YES@end
@interface NSString (Localized)@property (nonatomic, copy) NSString *oriStr; ///< 上次本地化的字符串原始值@property (nonatomic, copy) NSString *localizedStr; ///< oriStr 本地化后的字符串@end
复制代码

对 UILabel 的分类拓展可以判断 Label 是否需要被本地化;对 NSString 的分类拓展会对本地化后的结果进行缓存,当同一个 string 对象再次本地化时,可以快速从缓存拿到结果减少在 map 中的检索次数、提高效率。类拓展的方式也保证了本组件的侵入性极低。整个工程使用了 pod 进行集成,基础组件无需声明依赖,对本组件有依赖要求的只在特定业务中出现。hook + pod 的方式保证了本组件的灵活使用和充分解耦。


与 NSLocalizedString 的兼容


从上面的流程介绍可以看到,本地化替换发生在对 Label 设置文本的时候,不同于 NSLocalizedString 需要先显式本地化再设置文本的方式。所以,当使用方提前对文本进行了本地化,本组件的自动本地化不生效。考虑到本组件主要应用于新语言地区,NSLocalizedString 尚未配置对应的结果,故目前仍然可以使用本组件兜底。我们也会后续优化本组件,完成与 NSLocalizedString 的兼容,更加方便本组的使用。

拓展

由于上述方法只适用于[UILabel setText:]这种形式的无侵入调整,对于字符串拼接的情况,仍需要开发人员使用 LocalizedString 类对子串进行逐一本地化。同时,为了支持以后可能的应用内变更语言,LocalizedString 也提供了动态变更语言包功能。LocalizedString 主要 API 如下:


/** @brief 直接返回指定 key 对应的 本地化文字 @param key 转译文件表中的key */+ (NSString *)forKey:(NSString *)key;
/** @brief 根据指定的 language code,返回key 对应的 本地化文字 @param key 转译文件表中的key @param langCode语言编码 */+ (NSString *)forKey:(NSString *)key langCode:(NSString *)langCode;
/** @brief 设置当前默认的语言编码 @param langCode语言编码 */+ (void)setCurrentLangCode:(NSString *)langCode;
复制代码


总结

在多个产品同时的迭代情况下,使用组件化已经变得非常普遍,不断地重构优化组件来保证低耦合。当面对国际化场景时,需要沉淀打磨国际化适配框架来支撑业务高效迭代,并且不能给其他业务造成负担。目前以上功能都已上线,满足了产品的需求,解决了研发的痛点。

作者介绍

  • 吕洪阳,伴鱼 iOS 工程师,伴鱼绘本 iOS 端负责人

  • 赵杰,伴鱼 iOS 工程师,负责伴鱼绘本客户端研发,功能降级框架等工作

参考

https://developer.apple.com/documentation/uikit/uifonthttp://www.lingoes.cn/zh/translator/langcode.htm


作者:吕洪阳、赵杰

原文:https://tech.ipalfish.com/blog/2021/08/29/reading_ios_internationlization/

原文:iOS 文本的多语言适配和实践

来源:伴鱼技术博客

转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

2021-09-13 07:392855

评论

发布
暂无评论
发现更多内容

gopher成长之路(四):GO开发工程师写QT

非晓为骁

个人成长

工作想法小计2/7 - 2/11

非晓为骁

个人成长 开发 工作方式 Go 语言

LabVIEW跳转访问网页

不脱发的程序猿

LabVIEW 跳转访问网页

基于51单片机室内灯光控制系统

DS小龙哥

2月月更

RPA进阶(一):走近 RPA 世界

No Silver Bullet

RPA 机器人流程自动化 2月月更

Lyft微服务研发效能提升实践 | 2. 优化快速本地开发

俞凡

研发效能 大厂实践 2月月更 lyft

AI赋能安全技术总结与展望| 社区征文

herosunly

人工智能 新春征文 2月月更

鸿蒙学习笔记之使用 XML 方式创建布局

宇宙之一粟

鸿蒙 java UI 2月月更

消息队列存储消息数据的表结构

皓月

「架构实战营」

Kubernetes集群仪表盘dashboard&Kuboard安装Demo

山河已无恙

Kubernetes 2月月更

技术盘点:2022年云原生架构趋势解读

阿里巴巴云原生

阿里云 架构 云原生 趋势

kube-scheduler源码分析(1)-初始化与启动分析

良凯尔

源码 Kubernetes 容器 源码分析 #Kubernetes#

DOM 精通了?请问 Node 和 Element 有何区别?

编程三昧

JavaScript 前端 DOM 2月月更

“元认知”相关学习总结

panda

思维模型 阅读笔记 元认知

Go反射的三大法则

linlh

反射 元编程 Go 语言 2月月更

为什么需要单元测试?

蜜糖的代码注释

单元测试 后端开发 2月月更

技术盘点:云原生中间件的技术演进与未来趋势展望

阿里巴巴云原生

阿里云 云原生 中间件 趋势

AIGC的“含科量”与“含资量”

脑极体

一文带你了解 Java 的内存区域

宇宙之一粟

Java 内存 2月月更

电子书《大型组织深入推广零代码应用平台的行动指南》正式发布!

明道云

LabVIEW生成应用程序(exe)和安装程序(installer)

不脱发的程序猿

LabVIEW 生成应用程序(exe) 安装程序(installer)

战略规划和战略解码BLM+BEM

wood

bem 战略制定 300天创作 BLM

也许我们可以用另一种角度与观点看待世界所发生的事情,让你有所解答。

叶小鍵

设计消息队列存储消息数据的 MySQL 表格

swallowluo

架构实战营 #架构实战营 「架构实战营」

技术盘点:2022 年容器、Serverless、可观测、服务网格有哪些值得关注的趋势?

阿里巴巴云原生

阿里云 Serverless 云原生 趋势 可观测

Go 并发模式:管道和取消(译)

en

Go

【C语言】一维数组

謓泽

C语言 2月月更 一维数组

显示器选购总结-戴尔2705QM-明基PD2700U

李印

总结 经验分享

韵达基于云原生的业务中台建设 | 实战派

阿里巴巴云原生

阿里云 云原生 业务中台 合作案例

技术盘点:消息中间件的过去、现在和未来

阿里巴巴云原生

阿里云 云原生 中间件 消息队列 EventBridge

架构训练营 毕业设计

ren

iOS文本的多语言适配和实践_AI&大模型_伴鱼技术团队_InfoQ精选文章