Regarding the example I posted earlier, that's not intended for internationalization. I'd handle that with message resource bundles and set them based on locale or other setting at app init. I don't see a use case for cycling through languages. I've implemented my example for clients before who add custom fields to extend data structures. For example, my accounting software lets me extend contact information on a record, say "Kotlin Slack Handle" from the standard Name+Address+Phone Number. In that software, there is an open label / text field pair with a generic name like "Field 1".