[Pitch] Localized Swift Frameworks

Evolution Pitches
1

One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings files that contain translations of our APIs to other languages. From some other screenshots we see that Swift Playgrounds is providing translations of method names to explain them, here providing “avanzar” for “moveForward()”.

A scenario where Swift supported localized frameworks might see a .strings file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in the Swift file, or file extension (think “Foo.es.swift”), a developer who selects Spanish could simply write avanzar() and understand it in her native language. In fact, if the IDE is the layer that handles language selection, two developers who don’t even speak the same language could collaborate on code, and names from the framework would appear to each in their native language!

Comments and locally-defined names are of course still a barrier, but this isn’t new. I know that “mazu” means “first” in Japanese thanks to some code I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant effort to support, both technically in Swift itself and for those shipping Swift frameworks, both inside and outside of Apple, to provided localized names, so I wanted to throw this out to see if the community is even interested.

There’s just something about the idea of kids all over the world using Swift Playgrounds completely in their own language that makes me think this could help Swift achieve its stated goal of world dominance.

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

2

I wonder what it would do for reusability. It would be hard to share code
between countries written in Spanish or japanense unless the compiler could
convert the code to your language. Maybe properties and function calls
could be converted over to different languages but I am not sure Swift
keywords could be as easily converted which could lead to code with mixed
languages due to languages not mapping 1 to 1 on every word. This would be
really cool but a LOT of work. I think this is a bigger issue than just
adding it into Swift. Taking a look at non-English-based programming
languages -
Non-English-based programming languages - Wikipedia -
there are very few, if any, highly used languages on the list. Some
languages implemented symbols instead of words so that it is not language
based but that would cause breaking changes in Swift :)

It would be cool to see code in different languages:

for i in foo {
   print(i)
}

para i en foo {
   escribir(i)
}

···

On Fri, Mar 24, 2017 at 11:28 AM, Jeff Kelley via swift-evolution < swift-evolution@swift.org> wrote:

One of the things that struck me from today’s Apple press release about
Swift Playgrounds being localized in more languages is this screenshot:

All of the UI is fully localized for Chinese, *except* the actual code.
As far as I know, almost every major programming language and major
platform framework is primarily English; it’s become the *de facto *language
for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings
files that contain translations of our APIs to other languages. From some
other screenshots we see that Swift Playgrounds is providing translations
of method names to explain them, here providing “avanzar” for “
moveForward()”.

A scenario where Swift supported localized frameworks might see a .strings
file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in
the Swift file, or file extension (think “Foo.es.swift”), a developer who
selects Spanish could simply write avanzar() and understand it in her
native language. In fact, if the IDE is the layer that handles language
selection, two developers who don’t even speak the same language could
collaborate on code, and names from the framework would appear to each in
their native language!

Comments and locally-defined names are of course still a barrier, but this
isn’t new. I know that “mazu” means “first” in Japanese thanks to some code
I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant
effort to support, both technically in Swift itself and for those shipping
Swift frameworks, both inside and outside of Apple, to provided localized
names, so I wanted to throw this out to see if the community is even
interested.

There’s just something about the idea of kids all over the world using
Swift Playgrounds completely in their own language that makes me think this
could help Swift achieve its stated goal of world dominance.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Joshua Alvarado
alvaradojoshua0@gmail.com

3

I think one of the easiest ways to do it would be to ensure that the actual .swift files are all using the root language of the framework—akin to the development region of an app. Using metadata the IDE would dynamically substitute the localized names, but the underlying file would use the canonical values. Trying to store the localized code in the files makes using version control across language borders impossible.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

···

On Mar 24, 2017, at 2:03 PM, Joshua Alvarado <alvaradojoshua0@gmail.com> wrote:

I wonder what it would do for reusability. It would be hard to share code between countries written in Spanish or japanense unless the compiler could convert the code to your language. Maybe properties and function calls could be converted over to different languages but I am not sure Swift keywords could be as easily converted which could lead to code with mixed languages due to languages not mapping 1 to 1 on every word. This would be really cool but a LOT of work. I think this is a bigger issue than just adding it into Swift. Taking a look at non-English-based programming languages - Non-English-based programming languages - Wikipedia - there are very few, if any, highly used languages on the list. Some languages implemented symbols instead of words so that it is not language based but that would cause breaking changes in Swift :)

It would be cool to see code in different languages:

for i in foo {
   print(i)
}

para i en foo {
   escribir(i)
}

On Fri, Mar 24, 2017 at 11:28 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

<cn_playgrounds_looping.jpeg>

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings files that contain translations of our APIs to other languages. From some other screenshots we see that Swift Playgrounds is providing translations of method names to explain them, here providing “avanzar” for “moveForward()”.

<sp_playgrounds_stepping.jpeg>

A scenario where Swift supported localized frameworks might see a .strings file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in the Swift file, or file extension (think “Foo.es.swift”), a developer who selects Spanish could simply write avanzar() and understand it in her native language. In fact, if the IDE is the layer that handles language selection, two developers who don’t even speak the same language could collaborate on code, and names from the framework would appear to each in their native language!

Comments and locally-defined names are of course still a barrier, but this isn’t new. I know that “mazu” means “first” in Japanese thanks to some code I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant effort to support, both technically in Swift itself and for those shipping Swift frameworks, both inside and outside of Apple, to provided localized names, so I wanted to throw this out to see if the community is even interested.

There’s just something about the idea of kids all over the world using Swift Playgrounds completely in their own language that makes me think this could help Swift achieve its stated goal of world dominance.

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Joshua Alvarado
alvaradojoshua0@gmail.com <mailto:alvaradojoshua0@gmail.com>

4

This has already been done for a couple of languages and it always result in the same very nasty effect: It fragment the community. Trying to search for a method name or a compiler error message in google will returns only the results in your language.

This is incredibly frustrating, especially when your language is not English. I hate having to work with localized IDE and toolchain for that reason. Extending the localization to the language itself will just make the problem worse.

···

Le 24 mars 2017 à 18:28, Jeff Kelley via swift-evolution <swift-evolution@swift.org> a écrit :

One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

<cn_playgrounds_looping.jpeg>

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings files that contain translations of our APIs to other languages. From some other screenshots we see that Swift Playgrounds is providing translations of method names to explain them, here providing “avanzar” for “moveForward()”.

<sp_playgrounds_stepping.jpeg>

A scenario where Swift supported localized frameworks might see a .strings file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in the Swift file, or file extension (think “Foo.es.swift”), a developer who selects Spanish could simply write avanzar() and understand it in her native language. In fact, if the IDE is the layer that handles language selection, two developers who don’t even speak the same language could collaborate on code, and names from the framework would appear to each in their native language!

Comments and locally-defined names are of course still a barrier, but this isn’t new. I know that “mazu” means “first” in Japanese thanks to some code I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant effort to support, both technically in Swift itself and for those shipping Swift frameworks, both inside and outside of Apple, to provided localized names, so I wanted to throw this out to see if the community is even interested.

There’s just something about the idea of kids all over the world using Swift Playgrounds completely in their own language that makes me think this could help Swift achieve its stated goal of world dominance.

5

Hi Jeff,

This is something we discussed carefully early on in Swift’s development, and also while working on localizing Swift Playgrounds (an effort that has been underway for some time now). As others have said, localizing the language keywords fragments the language. Also, in the Apple ecosystem at least, all of the framework level documentation is written in English (there are some localized documents but comparatively rare). Also, interacting with frameworks involve the use of descriptive method names and argument keywords which are written in English.

All this adds up to needing to know English to some level in order to be a successful iOS developer, to successfully work with Foundation, and to successfully work with the Swift standard library. This posed the question of what to do in Playgrounds and what to do in the Swift language. Given the cost and risk of fragmenting the language, we decided that it is best to keep the language keywords themselves simple and consistent. The Swift Playgrounds curriculum followed its example (as well as that of the frameworks). In practice, talking to developers in other ecosystems, they can learn the meaning of a few terms that pop up, so this wasn’t a significant barrier for the goals of Swift Playgrounds - teaching the world to code.

That said, I’m sure the Apple folks will continue to evaluate whether localizing the Swift Playgrounds “API” (like moveForward()) makes sense (and it isn’t clear to me that that would be the best path). There are tradeoffs with doing so, but that team is compelled to build a dazzling product that is used around the world. If it makes sense on the balance, I’m sure they’ll jump on it.

-Chris

···

On Mar 24, 2017, at 10:28 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org> wrote:

One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

<cn_playgrounds_looping.jpeg>

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

6

+1

While I think this could be an incredibly useful feature that would make teaching coding to people much easier since they no longer need to learn English words at all, I think this can get really tricky when you consider autocomplete and all of the work an IDE has to do to identify the language then get the localized string and suggest that to the user. The huge amounts of words/verbs/functions/variables that would have to be dynamically localized could really slow down an IDE. And Xcode already has a hard enough time handling everything right now...

···

On Mar 24, 2017, at 12:33 PM, Jeff Kelley via swift-evolution <swift-evolution@swift.org> wrote:

I think one of the easiest ways to do it would be to ensure that the actual .swift files are all using the root language of the framework—akin to the development region of an app. Using metadata the IDE would dynamically substitute the localized names, but the underlying file would use the canonical values. Trying to store the localized code in the files makes using version control across language borders impossible.

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

On Mar 24, 2017, at 2:03 PM, Joshua Alvarado <alvaradojoshua0@gmail.com <mailto:alvaradojoshua0@gmail.com>> wrote:

I wonder what it would do for reusability. It would be hard to share code between countries written in Spanish or japanense unless the compiler could convert the code to your language. Maybe properties and function calls could be converted over to different languages but I am not sure Swift keywords could be as easily converted which could lead to code with mixed languages due to languages not mapping 1 to 1 on every word. This would be really cool but a LOT of work. I think this is a bigger issue than just adding it into Swift. Taking a look at non-English-based programming languages - Non-English-based programming languages - Wikipedia - there are very few, if any, highly used languages on the list. Some languages implemented symbols instead of words so that it is not language based but that would cause breaking changes in Swift :)

It would be cool to see code in different languages:

for i in foo {
   print(i)
}

para i en foo {
   escribir(i)
}

On Fri, Mar 24, 2017 at 11:28 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

<cn_playgrounds_looping.jpeg>

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings files that contain translations of our APIs to other languages. From some other screenshots we see that Swift Playgrounds is providing translations of method names to explain them, here providing “avanzar” for “moveForward()”.

<sp_playgrounds_stepping.jpeg>

A scenario where Swift supported localized frameworks might see a .strings file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in the Swift file, or file extension (think “Foo.es <foo.es), a developer who selects Spanish could simply write avanzar() and understand it in her native language. In fact, if the IDE is the layer that handles language selection, two developers who don’t even speak the same language could collaborate on code, and names from the framework would appear to each in their native language!

Comments and locally-defined names are of course still a barrier, but this isn’t new. I know that “mazu” means “first” in Japanese thanks to some code I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant effort to support, both technically in Swift itself and for those shipping Swift frameworks, both inside and outside of Apple, to provided localized names, so I wanted to throw this out to see if the community is even interested.

There’s just something about the idea of kids all over the world using Swift Playgrounds completely in their own language that makes me think this could help Swift achieve its stated goal of world dominance.

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Joshua Alvarado
alvaradojoshua0@gmail.com <mailto:alvaradojoshua0@gmail.com>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

<cn_playgrounds_looping.jpeg>

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings files that contain translations of our APIs to other languages. From some other screenshots we see that Swift Playgrounds is providing translations of method names to explain them, here providing “avanzar” for “moveForward()”.

<sp_playgrounds_stepping.jpeg>

A scenario where Swift supported localized frameworks might see a .strings file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in the Swift file, or file extension (think “Foo.es.swift”), a developer who selects Spanish could simply write avanzar() and understand it in her native language. In fact, if the IDE is the layer that handles language selection, two developers who don’t even speak the same language could collaborate on code, and names from the framework would appear to each in their native language!

Comments and locally-defined names are of course still a barrier, but this isn’t new. I know that “mazu” means “first” in Japanese thanks to some code I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant effort to support, both technically in Swift itself and for those shipping Swift frameworks, both inside and outside of Apple, to provided localized names, so I wanted to throw this out to see if the community is even interested.

There’s just something about the idea of kids all over the world using Swift Playgrounds completely in their own language that makes me think this could help Swift achieve its stated goal of world dominance.

This has already been done for a couple of languages and it always result in the same very nasty effect: It fragment the community. Trying to search for a method name or a compiler error message in google will returns only the results in your language.

This is incredibly frustrating, especially when your language is not English. I hate having to work with localized IDE and toolchain for that reason. Extending the localization to the language itself will just make the problem worse.

Amen to that!
Back in the days (pre inet) where localization for Mac’s was almost unavoidable I took the extra effort to order my computers in the US, specifically to avoid having to use localized machines.
While localized machines are necessary for some end-users, for me its a nightmare.

Rien.

OT: I have had this discussion more than once:

Me: Why is this mac more than twice the price in the US?
Seller: Because it is localized.
Me: But I don’t want a localized machine.
Seller: Uh, ok. I think I can do that… let me see… yes, it will take some time, but I can get you one…
Me: And will it then be cheaper?
Seller: No.

···

On 24 Mar 2017, at 21:40, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 24 mars 2017 à 18:28, Jeff Kelley via swift-evolution <swift-evolution@swift.org> a écrit :

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

I have to second (third) that.

Also, cosider the fact that there were very passionate debates about naming certain methods to follow Swift 3 API guidelines.

Who would localize the language? Enthusiasts? Who'd approve the localization? Would we allow anyone create his own? Imagine one school teaching with their localization, other school with another, each using different translations for various symbols.

Not to mention that there are languages that inflect nouns/verbs and the API guidelines wouldn't be applicable to many languages.

And lastely, the aforementioned burden of newcomers eventually learning native-language/English variations of all symbols...

···

On Mar 25, 2017, at 8:57 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote:

On 24 Mar 2017, at 21:40, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 24 mars 2017 à 18:28, Jeff Kelley via swift-evolution <swift-evolution@swift.org> a écrit :

One of the things that struck me from today’s Apple press release about Swift Playgrounds being localized in more languages is this screenshot:

<cn_playgrounds_looping.jpeg>

All of the UI is fully localized for Chinese, except the actual code. As far as I know, almost every major programming language and major platform framework is primarily English; it’s become the de facto language for developers. But does that have to be the case?

Imagine a world where alongside our Swift frameworks, we ship .strings files that contain translations of our APIs to other languages. From some other screenshots we see that Swift Playgrounds is providing translations of method names to explain them, here providing “avanzar” for “moveForward()”.

<sp_playgrounds_stepping.jpeg>

A scenario where Swift supported localized frameworks might see a .strings file with a format like this:

"moveForward()": "avanzar()"

Then, in Swift code, whether through an IDE, some metadata in a comment in the Swift file, or file extension (think “Foo.es.swift”), a developer who selects Spanish could simply write avanzar() and understand it in her native language. In fact, if the IDE is the layer that handles language selection, two developers who don’t even speak the same language could collaborate on code, and names from the framework would appear to each in their native language!

Comments and locally-defined names are of course still a barrier, but this isn’t new. I know that “mazu” means “first” in Japanese thanks to some code I worked on with an old coworker.

This is obviously out of scope for Swift 4, and would require significant effort to support, both technically in Swift itself and for those shipping Swift frameworks, both inside and outside of Apple, to provided localized names, so I wanted to throw this out to see if the community is even interested.

There’s just something about the idea of kids all over the world using Swift Playgrounds completely in their own language that makes me think this could help Swift achieve its stated goal of world dominance.

This has already been done for a couple of languages and it always result in the same very nasty effect: It fragment the community. Trying to search for a method name or a compiler error message in google will returns only the results in your language.

This is incredibly frustrating, especially when your language is not English. I hate having to work with localized IDE and toolchain for that reason. Extending the localization to the language itself will just make the problem worse.

Amen to that!
Back in the days (pre inet) where localization for Mac’s was almost unavoidable I took the extra effort to order my computers in the US, specifically to avoid having to use localized machines.
While localized machines are necessary for some end-users, for me its a nightmare.

Rien.

OT: I have had this discussion more than once:

Me: Why is this mac more than twice the price in the US?
Seller: Because it is localized.
Me: But I don’t want a localized machine.
Seller: Uh, ok. I think I can do that… let me see… yes, it will take some time, but I can get you one…
Me: And will it then be cheaper?
Seller: No.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution