Add discussion of Kotlish dialect

Author: marcprux

src/content/docs/docs/modes.md

@@ -71,8 +71,8 @@ The following diagram depicts a pure transpiled project:
 
 Transpiled mode's advantages and disadvantages are mirror opposites of native mode's.
 
-- **Integration with Android APIs**. The primary benefit of transpilation is near-perfect integration with Android's Kotlin and Java APIs. Because your Swift code is converted to Kotlin, it can [directly call other Kotlin API](/docs/platformcustomization/), just as if it were calling Swift. And because the Kotlin language features seamless integration with Java, your Swift code can call Java API as well. Unlike native mode, no [bridging](#bridging) is required.
-- **Transparency**. Transpilation allows you to see and understand all of Skip’s output. Skip’s Kotlin is fully human-readable and even overridable: Skip includes the ability to [insert or substitute literal Kotlin](/docs/platformcustomization/#skip-comments) inline with your Swift. This is of particular use during [debugging](/docs/debugging/), where you get full stack traces and can take full advantage of Andriod's debugging tools to step through your generated Kotlin.
+- **Integration with Android APIs**. The primary benefit of transpilation is near-perfect integration with Android’s Kotlin and Java APIs. Because your Swift code is converted to Kotlin, it can [directly call other Kotlin API](/docs/platformcustomization/), just as if it were calling Swift. We call this hybrid dialect [Kotlish](/docs/swiftsupport/#kotlish): syntactically Swift, but semantically Kotlin. And because the Kotlin language features seamless integration with Java, your Swift code can call Java API as well. Unlike native mode, no [bridging](#bridging) is required.
+- **Transparency**. Transpilation allows you to see and understand all of Skip’s output. Skip’s Kotlin is fully human-readable and even overridable: Skip includes the ability to [insert or substitute literal Kotlin](/docs/platformcustomization/#skip-comments) inline with your Swift. This is of particular use during [debugging](/docs/debugging/), where you get full stack traces and can take full advantage of Andriod’s debugging tools to step through your generated Kotlin.
 - **Ejectability**. If Skip were to disappear, transpiled mode still gives you the full source code to both the iOS and Android versions of your app. You could continue to evolve the app as separate iOS and Android codebases (which is how many dual-platform apps are developed). Skip does not have any required runtime components other than the libraries it uses to provide the Foundation, SwiftUI, etc APIs on Android, and these libraries are all [free and open-source](https://source.skip.tools). 
 - **App size**. Transpiled apps don't have to bundle anything but Skip's relatively slim compatibility libraries, while native apps have to include the much larger Swift Foundation and internationalization libraries.
 - **Build time**. The combination of Skip's transpiler and the Android Kotlin compiler is faster than building with the full native Swift toolchain when iterating on your Android code.
@@ -327,7 +327,7 @@ See the [Bridging Support Reference](/docs/bridging/) for additional information
 
 Skip offers multiple options for consuming Kotlin/Java API in native Swift. The most comprehensive is to bridge a transpiled Swift module.
 
-Skip's ability to transpile Swift to Kotlin is one of its strengths. Transpiled Swift code effectively *is* Kotlin, which gives it a superpower: it can directly call any other Kotlin/Java APIs, with no bridging or configuration, just as if they were written in Swift. The Skip [documentation](/docs/platformcustomization/#calling-kotlin-api) provides details.
+Skip's ability to transpile Swift to Kotlin is one of its strengths. Transpiled Swift code effectively *is* Kotlin (we call this hybrid dialect [Kotlish](/docs/swiftsupport/#kotlish)), which gives it a superpower: it can directly call any other Kotlin/Java APIs, with no bridging or configuration, just as if they were written in Swift. The Skip [documentation](/docs/platformcustomization/#calling-kotlin-api) provides details.
 
 When you enable bridging on a transpiled module and expose its API to native Swift, you are also exposing this superpower. How? Let's consider an example. Suppose that your native Swift wants to store sensitive data in Android's encrypted shared preferences, which are only accessible via Kotlin. We choose to make a reusable library to expose this functionality to Swift.
 

src/content/docs/docs/platformcustomization.md

@@ -91,6 +91,8 @@ If you are using [Skip Lite](/docs/modes/#lite), *all* of your Swift is transpil
 
 When you call Kotlin and Java code from within transpiled `#if SKIP` blocks, remember that you are still writing *in Swift*. The code is still parsed by Xcode, so it must have valid Swift syntax. But it is excluded from your iOS build and invisible to the Swift compiler, which allows it to make any syntactically valid API call without causing Xcode errors. Just write natural Swift code, and imagine that the Kotlin or Java API you're calling is a Swift library API. Skip's transpiler will take care of the rest.
 
+We sometimes call this hybrid dialect [Kotlish](/docs/swiftsupport/#kotlish): code that is syntactically Swift but transpiles to Kotlin. The [Kotlish documentation](/docs/swiftsupport/#kotlish) covers the dialect in depth, including its limitations and the escape hatches available when the transpiler needs a hand.
+
 If you're attempting to cut and paste Kotlin inline, you'll have to turn it into valid Swift to avoid syntax errors. Luckily, the languages are extremely similar. You'll typically only have to change a few calling conventions:
 
 - Named parameter values in Kotlin are specified with an equals (`=`) sign, whereas in Swift they use a colon (`:`). Note that parameter names are never required in Kotlin.