由于每种语言的词语长度和语句结构存在差异，因此开发者在进行引用本地化时，同样的一句话被翻译成不同的语言，文字长度往往会增长或缩短 30% 左右（例如英语和西班牙语的翻译）。 这个问题可能给开发者带来麻烦，因为有些设计的界面容纳不了翻译后的文本。
解决办法：总结不同语言翻译后的变化情况，在此基础上为翻译人员提供优先保留的信息，并限制翻译后的字数，以便他们削减内容。
本地化的一个重要步骤是确保语言的复数形式是正确的。 不同的语言有不同的复数使用规则，比如英语中只有单数和复数两种形式。 英语的单复数形式看起来比较简单，但并不意味着其他语言也很简单，相反，有些语言的复数形式比较繁杂。比如在俄语中，以1结尾的数字（除了 11）、以 2~4 结尾的数字（除了 12 和 14）和其他数字之间存在不同的语言形式。 这意味着，把翻译的文本输入应用内部时，设备可能无法识别两项内容：1）哪些词是复数；2）他们的复数形式是什么。这种情况在法语中更为严重，因为法语的语法结构更为复杂。
解决办法： 不同的框架构建出来的 app 处理语法复数形式的规则也不同。Android 和 iOS 平台都有许多处理复数形式的代码资源，我们可以利用这些资源，保证翻译后的复数符合当地语言习惯。(由于部分限制无法放出相关链接)
从产品中提取字符串的主要问题之一，是没有直接的方法和更有效的工具来进行提取。正是因为没有标准化、结构化的流程，所以本地化的技术问题在解决时十分具有挑战性。
解决办法： 对于 iOS 和 Android 的应用，Xcode 和 Android 工作室有内置的功能提取字符串。对于其他应用，有很多可用的工具，例如 gettext，l10n.js 和 Rails i18n。
本地化的技术工作流程涉及大量的手动步骤：提取字符串、测试字符串、将它们上传至平台，然后将所有字符串重新集成到产品中。这一系列工作需要消耗许多时间，而且大部分时间可能花费在某些比较繁琐的步骤上。
解决办法: 寻找翻译平台时，优先考虑有相关 API 的平台，因为这有助于节省时间。
如果在字符串提取中出现错误（提取错误或字符串丢失），那么在完成整个翻译过程之后就无法得知字符串是否有效和正常运行。 这项工作既费时又费力，更不用说还需要手动通过代码来找到错误。
解决办法： 一般来说，行业标准的解决办法是“伪本地化”，即产品文本被替换成直译而不是专业翻译的内容，这是为了便于提前检查本地化的产品。通过使用明显的直译，还能够揭示哪些编码字符串可供翻译，并找到不应该或不能翻译的字符串。另外，它还可以识别影响本地化产品的设计/布局问题。
以上为应用本地化中常见的 5 个问题，其实这样的问题还有很多。对于开发者来说，由于国内应用市场竞争激烈，出海是国内应用未来的发展方向之一，而目前国内出海的产品在国外进展并不是十分顺利，因此更需要开发者们或应用本地化翻译人员耐心总结经验。除此之外，产品本身应该是被关注的焦点，充分了解和融入当地的用户习惯、文化特点、语言方式、政策与宗教等更能帮助应用在国外立稳脚跟。