从文件路径加载笔尖

发布于 2024-11-30 07:00:38 字数 276 浏览 0 评论 0原文

我们可能需要使用

[NSBundle -pathForResource:ofType:inDirectory:forLocalization:]

我认为这是可能的结果来加载笔尖,但我能找到的所有方法只需要名称而不需要引导路径信息。

我们正在探索一种通过一个代码库同时提供 fr-Fr 和 fr-CA 的方法。我们的客户想要 fr-CA 翻译,我们担心可能会有另一个客户想要 fr-Fr 翻译。我想我们可以根据所选语言找到正确的笔尖。

谢谢

We might have a need for loading a nib using the results of

[NSBundle -pathForResource:ofType:inDirectory:forLocalization:]

I thought this would be possible, but all the methods I can find only want the name not leading path info.

We are exploring a way to provide both fr-Fr and fr-CA through one code base. Our client wants a fr-CA translation and we're afraid we might have another customer that wants a fr-Fr translation. I was thinking we could path to correct nib based on the selected language.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

迷乱花海 2024-12-07 07:00:38

路径查找考虑了用户的区域设置首选项。如果您提供正确的本地化目录 (.lproj),系统应该加载正确的笔尖。

根据 Apple 文档

该方法首先在指定包的非本地化资源目录中查找匹配的资源文件。 (在 Mac OS X 中,该目录通常称为 Resources,但在 iOS 中,它是主捆绑包目录。)如果未找到匹配的资源文件,则会在任何可用的特定于语言的“.lproj”的顶层进行查找目录。 (特定于语言的目录的搜索顺序与用户的首选项相对应。)它不会递归通过任何这些位置的其他子目录。有关更多详细信息,请参阅国际化编程主题。

不幸的是,苹果的文档是自相矛盾且不完整的。如果您查看“国际化和编程主题”的“语言和区域设置指定”部分,您将在“语言和区域设置 ID”下找到这个宝石:

重要提示:在 iOS 中,捆绑包接口在查找本地化资源时不会考虑方言或脚本信息;仅考虑语言指示符代码。因此,如果您的项目包含具有语言和区域指示符的特定于语言的项目目录,则这些目录将被忽略。 Mac OS X 中的捆绑包接口确实支持特定于语言的项目目录中的区域指示符。

这并不完全正确。如果您查看 Apple 自己的应用程序,您会发现 iOS 确实支持某些区域指定,但仅限于 Apple 关心的区域。例如,请参阅最近的 Mobile Safari 中的 .lproj 目录列表:

$ ls -d *.lproj
Dutch.lproj/    el.lproj/       pt_PT.lproj/
English.lproj/  en_GB.lproj/    ro.lproj/
French.lproj/   fi.lproj/       ru.lproj/
German.lproj/   he.lproj/       sk.lproj/
Italian.lproj/  hr.lproj/       sv.lproj/
Japanese.lproj/ hu.lproj/       th.lproj/
Spanish.lproj/  id.lproj/       tr.lproj/
ar.lproj/       ko.lproj/       uk.lproj/
ca.lproj/       no.lproj/       vi.lproj/
cs.lproj/       pl.lproj/       zh_CN.lproj/
da.lproj/       pt.lproj/       zh_TW.lproj/

请注意,支持两个中文区域、一个英式英语区域和一个葡萄牙葡萄牙语区域​​。但这些都没有解决 fr_CAfr_FR 的问题。

为此,让我们再次看看 MobileSafari。它必须实现自己的智能查找,因为它有大量更精细区分的 StaticBookmarks-xx_YY.plist 文件。

所以,这就是解决方案:使用仍然可用的区域设置函数,并相应地进行自己的查找。

The path lookup takes into account the user's locale preferences. If you provide the proper localization directories (.lproj), the right nib should be loaded by the system.

Per Apple's documentation:

The method first looks for a matching resource file in the non-localized resource directory of the specified bundle. (In Mac OS X, this directory is typically called Resources but in iOS, it is the main bundle directory.) If a matching resource file is not found, it then looks in the top level of any available language-specific “.lproj” directories. (The search order for the language-specific directories corresponds to the user’s preferences.) It does not recurse through other subdirectories at any of these locations. For more details see Internationalization Programming Topics.

Unfortunately, Apple's documentation is self-contradictory and incomplete. If you look at "Internationalization and Programming Topics", section "Language and Locale Designations", you will find under "Language and Locale IDs" this gem:

Important: In iOS, the bundle interfaces do not take dialect or script information into account when looking for localized resources; only the language designator code is considered. Therefore if your project includes language-specific project directories with both a language and region designator, those directories are ignored. The bundle interfaces in Mac OS X do support region designators in language-specific project directories.

This is not entirely true. If you look at Apple's own applications, you will see that iOS does support some region designations, but only the ones Apple cares about. See for example the list of .lproj directories in a recent Mobile Safari:

$ ls -d *.lproj
Dutch.lproj/    el.lproj/       pt_PT.lproj/
English.lproj/  en_GB.lproj/    ro.lproj/
French.lproj/   fi.lproj/       ru.lproj/
German.lproj/   he.lproj/       sk.lproj/
Italian.lproj/  hr.lproj/       sv.lproj/
Japanese.lproj/ hu.lproj/       th.lproj/
Spanish.lproj/  id.lproj/       tr.lproj/
ar.lproj/       ko.lproj/       uk.lproj/
ca.lproj/       no.lproj/       vi.lproj/
cs.lproj/       pl.lproj/       zh_CN.lproj/
da.lproj/       pt.lproj/       zh_TW.lproj/

Notice that two Chinese regions, a British English region, and a Portugal Portuguese region are supported. But none of these solves the problem of fr_CA versus fr_FR.

For that, let's look at MobileSafari again. It must implement its own smart lookup, because it has plenty of more finely distinguished StaticBookmarks-xx_YY.plist files.

So, that's the solution: Use the locale functions that are still available, and do your own lookup accordingly.

恏ㄋ傷疤忘ㄋ疼 2024-12-07 07:00:38

我不明白这个问题。
您可以完美地拥有两个不同的 NIB,分别用于法国和加拿大(法语),因为 Xcode 支持它。

只需为您的文件添加新的本地化:

在此处输入图像描述

然后使用视图控制器加载 NIB, initWithNibName 方法。根据设备语言设置,将使用正确的语言。

I don't understand the problem.
You can perfectly have two different NIBs, for France and Canada (french), as it's supported by Xcode.

Simply add new localization for your file(s):

enter image description here

Then use a view controller to load the NIB, with the initWithNibName method. The correct one will be used, depending on the device language settings.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文