Is the plan that Compose will use the framework's app resource system, eg res/drawable-land etc? All the snippets I've seen show things like

Text ("Hello World")

instead of

Text (R.string.hello_world)

most of the examples just show string because we don’t have a well-formed answer around this yet. Also because strings are just simpler to show 🙂 The current resource system will continue to work, and any kotlin code you can use to grab those resources will continue to work. The new UI Toolkit (Compose UI) may have a redesigned resource system, but we’re still not sure what that would look like yet, or if it will happen (Not super involved with this part of it personally, so someone can correct me if this isn’t entirely accurate)

I guess Compose goal is to be multiplatform at some point, and that means platform agnostic resources referencing and usage. Side-note: I strongly dislike Android's string resources that require to escape all the apostrophes or single quotes

'

manually. Raw string literals are better regarding this (except when you want to have double quotes at the beginning/end of a string, or triple+ quotes anywhere inside). I hope we get something better for l10n and i18n with what will work with Compose.

You need some way to store translations anyway, xml isn't too bad for that.

There will be a way to do this as a one-liner one way or another, if only because people have tons of existing resources if nothing else

Many Android developers are used to xml, but xml is not designed to be human readable. It adds restrictions like escaping some characters, not handling line breaks in a natural way, and adds verbosity like the tags and the attribute quotes. Take JSON (with quotes) and Kotlin DSL (no quotes). What is more readable? You already know the answer.

So you'd prefer if aapt would accept json string resource files assuming nothing else changed?

So yeah, xml isn't too bad, but I don't want to say it (nor hear/read it) because when we say something isn't too bad, it means we accept settling for repeated "little" pain (let's not mention programming languages 😅 ). Of course it depends on context, but for a page as "blank" as Compose and the Kotlin multiplatform ecosystem, we are not required to choose something that we know does not meet the standard experience we hope for.

i built a translation system at airbnb that i thought worked pretty well. Basically, you would have a special function, like

t

and it would accept the default string translation, and some context string. ie,

Button(text=t("Sign Up!", "The sign up button on the main screen"))

. We then had a compiler plugin that would go find all instances of these, and as part of our CI process would communicate with our translation service with any new strings and put them in the queue to get translated. You could then have

t(...)

return the translated string at runtime. The compiler can do the translations at build time, too, but we wanted to be able to push updated translations over the air, so the runtime conversion worked better.

I guess in the absence of a super strong opinion here I'd be happy to use something else off the shelf, whether that's the existing format or something else

can you explain? not sure i understand

I think it assumes a lot of things we would consider good practice but that can't be taken for granted, like the CI pipeline you described

My biggest question about that would be how you handle string reuse across multiple locations

In some other place you would have

"Sign Up" to "הירשם"

which is prone to typos

The string reuse was built into the system

@Fudge yeah. If you assume a lot of tooling around the pipeline you can make it work

technically if you had two “Sign Up!” strings with different context strings, it would be two different “keys”

The former i18n dev in me feels like he should point out that

"The sign up button on the main screen"

is a really bad example of a context string 😛

but our backend would see that one translation already existed, and default to that, but put it in the queue for a translater to differentiate based on the context string

Oh I totally agree

yep, same!

But my broader point was that generally "Sign up!" should have the same context basically everywhere it's used in the app

hmm. actually i don’t necessarily agree with that

@louiscad part of what makes the kotlin ecosystem great is that it's full of pragmatic decisions to reuse even when there are tradeoffs involved. See: the baggage we inherited around generics, lack of value types, etc 🙂

with that context being something like "The text of a button for the user to create an account for the service"

but for instance, a string like “OK” might be the same translation in english in a lot of places, but a different translation for other languages depending on the context

Aren't inline classes essentially value types?

Only if they fit in a primitive

We generally tried to use context to make sure the translator understood the exact meaning we were trying to convey, so if it means the same thing throughout the app, it has the same context.

yeah - that makes sense. i could see the primary call to action button having a different translation than, for instance, a secondary smaller button though. but in this example the likelihood of reuse is high

Once you've provided that much context in place you start to lose the thread reading the surrounding code, I'd fear

Hopefully this isn't too tangential, but the main problem I have with strings at the moment is the dependency on `context`/`resources` it creates. I'm not sure if that's a solvable problem, but it makes unit testing a major concern when creating a function like

t

that Leland mentioned. Using that function in places you'd like to JVM test becomes challenging. I have no idea how Compose could fix/change/work around that. Just a pain point I have.

Leland, your code is very familiar of https://developer.apple.com/documentation/foundation/nslocalizedstring

Yeah I think working around that part of it at least is a goal, @alexsullivan114

Really? That's....amazing. I don't fully understand how you'd work around that but I'm excited to see!

Flutter uses JSON for localized strings.

Not really

@alexsullivan114 at a minimum a function layer that abstracts over grab current context/fetch resource and does something else host side 🙂

I'm not sure what "host side" means but I accept the magic and am jazzed!

host side ~= “JVM” or “Desktop”

Interesting. I'm not up to date on the latest in the "compose is a platform agnostic library" discussion

yeah i found it to be an odd term too first time i heard it

The approach used by IOS does look very nice, it could be something of the sort

"The button was pressed %d times".localized(20)

Careful with that example though because now you start throwing plurals into the mix

@itnoles that does look similar. ironically, we used a hand-rolled system on ios as well. don’t remember why

Yeah the terms refer to host vs. target (the Android device), it's used during Android platform builds and elsewhere

we had a special way of doing pluralization. pluralization is quite difficult

Not all strings need context (not that

Context

). For example "Sign up" is likely to not need it and be usable anywhere in the app. Some other strings need context though, but IMHO, to make translators lives easier, this context should have grouping, a hierarchy that the developers can define, which could have shorthand identifiers. The place where the strings/translations would be defined for a context could embed comments (easier than xml comments hopefully), to give more information about the context. The translators would read it to see where to navigate in the real app for example, or understand what a particular acronym stands for and the translations known to the developer (which maye code in English but may not be English native and have to translate an acronym from his language to English, potentially leaving misunderstandings or inaccuracies behind to the translator for additional languages). I think grouping/hierarchy would be of great help for multiscreen apps, which are plenty, and would more valuable as your app gets a deep UI.

I've seen designers get very prescriptive around things like sentence case vs title case and punctuation for different parts of a UI that might have otherwise the same string; there's a ton of metadata to consider

A surprising amount of translation tooling just ignores pluralization, which makes it borderline useless if you're translating into any significant number of languages.

Yeah, pluralization, fun stuff:

4 kids are playing 2 games.

,

1 kid is playing one game.

,

Four kids are playing 1 game.

.

That iOS example doesn't work though, does it? I was slapped down after trying to create a

localized

extension function since whatever tool iOS developers run specifically looks for

NSLocalizedString

calls when it builds up the translations

@alexsullivan114

extension String {
    var localized: String {
        return NSLocalizedString(self, tableName: nil, bundle: Bundle.main, value: "", comment: "")
    }
}

?

i don’t know NSLocalizedString gathers its dataset automatically, but at airbnb it would have had that issue at well. - we required string literals for things to compile correctly, as we looked for those calls specifically. it was a little bit hacky. not sure it’s the right solution here, but if ios does a similar thing, that would be an interesting precedent.

yup, Localizable.strings

I understand the extension function, and maybe my data is out of date or wrong, but I thought that wouldn't work because genstrings looks for specific uses of

NSLocalizedString

. So that extension function would result in just one localized string rather than all of the different uses of that function. Again, that could be wrong. iOS isn't my core strength. Also this is tangential to the conversation so we should probably drop it for now

I didn't mean that's how IOS does it, just that that's how it could look in Kotlin @alexsullivan114.

With that extensions, you have to do like "Context".localized

Not all strings need context (not that

Context

). For example "Sign up" is likely to not need it and be usable anywhere in the app.

Disagree here, every string should have context that describes the thing in as plain and jargon-free a way as possible in order to help translators make sense of it. "Sign up" is a very idiomatic phrase in English, imagine a language that doesn't have that phrase - would "Create account" be appropriate? The translator doesn't necessarily even know if your service has accounts, maybe it's a magazine or mailing list or something. Of course, you can probably get away with a lot less context if you have translators familiar with your product.

I’d would be happy to throw out all of the xml and use some proper kotlin dsl’s instead

After reading this discussion, i think i know who should implement the localization part of compose :) very useful.

Same with @alexsullivan114, no matter what you do, please, get rid of the

android.content.Context

. People are bending over and going great lengths just to workaround a simple case like unit testing formatted string (because of Context). https://kotlinlang.slack.com/archives/C5GB1NDGE/p1550527639020200?thread_ts=1550527639.020200&cid=C5GB1NDGE

Why not use kotlin extension methods with sealed classes so we can use non receiver specific code for "general" strings and use extension function for context specific. It will look something similar to this (forgive me if it looks bad I'm writing from my phone) sealed class Strings { open val someString: String = "value" } //Context specific strings sealed class MainActivityStrings(mainActivity: MainActivity) : Strings { override val someString: String = "main activity value" } Or something in that area

I took a stab at something like this in K/N https://github.com/designatednerd/KotlinNativeTest/blob/master/SharedCode/src/commonMain/kotlin/localization/StringStorage.kt

Would be interesting to have something like this:

val `The sign up button on the main screen` = LocalizationString("Sign Up", "הירשם")

val `The login button on the main screen` = LocalizationString("Log in","היכנס")

But android doesn't support identifiers with spaces 😞

I guess so, but I don't know how much we want to be "Multi platform positive" especially when Flutter exists

@ghedeon I'd like to understand that use-case a bit better - why do you need to delay involvement of the Context? Generally the conversion of data -> UI strings is the purview of the view layer, rather than part of the model. It's configuration-dependent, so you need to know the configuration in order to properly resolve the strings. Is this mostly an issue in testing? e.g., you're trying to do host-side unit tests without using Robolectric or something similar

@Ryan Mentley "domain data --> view state" is in presentation layer, that's right. So is the ViewModel, that supposed to be unit testable and android dependencies free. But it's not easy to keep it like that. Ex: VM is feeding some dynamic strings for the view to render. It's an instant problem, because in order to format the message you need context... (I don't consider

AndroidViewModel

or Context injection because it's a hack). Same with drawables. Ex: Based on some app logic, the VM is setting different icons to the view. As long as it's an

R.drawable.ic_foo

it's ok, but applying color filter will require the context. To summarize: you want to take some decisions about the model of the view in the controller (VM) and before actual rendering.

i think what ryan is getting at is… what if it was easy to create a test context without depending on android or requiring a device / robolectric? would you feel like it is no longer a problem at that point?

It sounds like you're mixing your view and your viewmodel. Your VM shouldn't be setting icons, for instance - the VM provides the data that the View uses to set the icon.

I see. People come up with those resource wrappers mostly because of tests. Thus, I expect a "test context" to eliminate the pain point. I'm unsure about purity concerns and multiplatform considerations... Like, in ideal world, Interactors(UseCases) are supposed to be platform independent, right? What about view models?

I'd say by the time you've converted to a string, you've already "rendered" the data. To me, the ViewModel is anything that's agnostic of how you display the information (it contains the information itself). If I had a different UI that displayed the exchange rate differently, I wouldn't want that string; I'd want the amounts and the currencies. Thus, the View is (and should be) responsible for formatting the data.

This way VM is more generic. Do we want generic viewmodels? That reminds me about MVC days, when one controller for multiple views was quite common. I might be wrong, but I don't see it often nowadays.

Thanks for the input! It's helpful to get perspectives on what's tricky for people currently to help shape things for the future.

Thus, the View is (and should be) responsible for formatting the data.

Still though, if the formatting we are talking about is the “total price” line of a page that generates 100% of your business’s revenue, you want to be able to test it.

Definitely, but at that point you're testing the UI

yeah i guess i’m saying that i don’t think that it’s unreasonable to unit test view models, and include “formatting” in the set of things that a viewmodel is responsible for. i’m actually not sure if i think the framework view layer should be responsible for text formatting at all. or at least if it should be, it’s not clear to me why

Also to be clear I'm definitely not suggesting that view models shouldn't be unit tested