search

Flutter-Bounty-Hunters / swift_ui

Flutter port of Swift UI
MIT License
63 stars 4 forks source link

[Spec] - Text: Localization #6

Closed matthew-carroll closed 8 months ago

matthew-carroll commented 9 months ago

Research the Text view for localization, add relevant Swift UI examples, and add spec details to the relevant Wiki page.

matthew-carroll commented 8 months ago

@Maatteogekko now that your PR is merged, how is the spec'ing process coming?

Maatteogekko commented 8 months ago

I have been working on it, it should be ready for tomorrow

Maatteogekko commented 8 months ago

Just updated the spec. I didn't go deep on the initializers for LocalizedStringResource, String and AttributedString. Since they are used across different Views, we should write a specification for each of them. The same goes for the grammatical agreement section.

matthew-carroll commented 8 months ago

Thanks @Maatteogekko. It's probably correct that those other artifacts should be spec'd in their own document(s).

Here are some comments on what you wrote in the spec.

The Text widget is just one of the many places where localization plays an important role. Well, one could argue that it is one of the most important, since it is text that is translated. Localization does not affect the UI or fidelity of the app, instead it plays a subtler role: good localization is inviting, and makes the user feel at home when using the app.

The most important part in getting localization right is the developer experience: the easier it is to export, translate, import strings in the app, the handling of plurals, the correct use of pronouns and genres, the better the user experience will be. SwiftUI and Xcode offer many tools to help improve the localization experience for the developer, but there are also some legacy standards that should be avoided.

SwiftUI is not the only UI framework developed by Apple to build natively on Apple platforms. UIKit and AppKit are older frameworks, but still widely used. They can even be integrated inside SwiftUI. Some localization constructs are shared between these frameworks and since SwftUI is the youngest of the family, there are some limitations or awkward edge cases when using some of them. They will be noted where relevant.

These specs are intended to concisely provide developers with the information needed to recreate the associated Swift UI behavior. Therefore, there's no need for general education about the topic of localization, typography, etc. We just want to capture the Swift UI behaviors for the given UX area in the spec.

Supporting multiple languages in your app is a good overview of the tools available for localization. Look at Xcode's localization documentation for more information and examples.

You provided a couple links early on. If those links are purely supplemental then that's fine, but if there's any information in those links that is necessary and relevant for the Text View then that information should be provided directly within the spec. We don't want readers to have to follow links for necessary information.

String and AttributedString are awkward to work with in swiftUI (localization-wise, at least), and don't seem to be completely supported

Can you elaborate on which features aren't supported?

A String catalog is a json file with the .xcstrings extension, and the convention is to name them LocalizableXXX (eg. LocalizableFoo, LocalizableBar)

What should the Foo and Bar be? Are those supposed to be language names, e.g. LocalizableSpanish? Or something else.

Note: There are other mechanisms like this, that affect all localizable strings, even outside the Text view, that need their own specification. It's unclear how we can achieve something similar in the swift_ui package.

Other mechanisms like what?

Maatteogekko commented 8 months ago

Thank you @matthew-carroll. I made some modification to address your feedback, please let me know if there is anything else to improve.

PS. regarding the links, they are indeed supplemental: it's good background to have when working with localization

matthew-carroll commented 8 months ago

Thanks @Maatteogekko - it looks like a good starting point. I'm sure we'll need to investigate things like the lookup table and automatic grammar adjustments when we get into the code. I get the sense that those are things that we'll need Flutter to provide. Perhaps we'll file some tickets.

I'll close this issue for now. Please ensure the spreadsheet is updated accordingly.

Would you like to repeat this process for the Image View? I'm sure there's very little involved with Image, but there might be some details, such as localizing the image title or label or whatever Swift UI supports.