Issue/sbt lowercase

ja/overviews/macros/overview.md

@@ -217,9 +217,9 @@ Scala コードの生成については[リフレクションの概要](http://d
 このシナリオは前節で説明したとおりだ。つまり、マクロとそれを使用するコードを別に呼び出した `scalac` によってコンパイルすることで、全てうまくいくはずだ。REPL をつかっているなら、さらに都合がいい。なぜなら REPL はそれぞれの行を独立したコンパイルとして扱うため、マクロを定義してすぐに使うことができる。
 
 <a name="using_macros_with_maven_or_sbt">&nbsp;</a>
-### Maven か SBT を用いてマクロを使う
+### Maven か sbt を用いてマクロを使う
 
-本稿での具体例では最もシンプルなコマンドラインのコンパイルを使っているが、マクロは Maven や SBT などのビルドツールからも使うことができる。完結した具体例としては [https://github.com/scalamacros/sbt-example](https://github.com/scalamacros/sbt-example) か [https://github.com/scalamacros/maven-example](https://github.com/scalamacros/maven-example) を見てほしいが、要点は以下の 2点だ:
+本稿での具体例では最もシンプルなコマンドラインのコンパイルを使っているが、マクロは Maven や sbt などのビルドツールからも使うことができる。完結した具体例としては [https://github.com/scalamacros/sbt-example](https://github.com/scalamacros/sbt-example) か [https://github.com/scalamacros/maven-example](https://github.com/scalamacros/maven-example) を見てほしいが、要点は以下の 2点だ:
 
 <ul>
 <li>マクロは、scala-reflect.jar をライブラリ依存性として必要とする。</li>

news/_posts/2012-12-12-functional-programming-principles-in-scala-impressions-and-statistics.md

@@ -102,7 +102,7 @@ Given sufficient interest, we're planning on posting a follow-up blog article wi
 
 ## Closing Thoughts
 
-Overall, it was an intense 7 weeks for us as well as the course students. Organizing a MOOC is no small matter. We could count on the help the EPFL team, with Lukas Rytz, Nada Amin, Vojin Jovanovic and Manohar Jonnalagedda who designed and implemented the grading infrastructure, prepared the setup instructions, designed the homeworks, and edited the videos and quizzes; Tao Lee, who did most of the video cutting and editing, Tobias Schlatter, who worked tirelessly answering questions on the discussion boards, Pedro Pinto, who designed the recording equipment setup, and Nastaran Fatemi Odersky who did content editing. Many people at Typesafe also helped, in particular the IDE team around Iulian Dragos and Mirco Dotta who implemented the worksheet software and Josh Suereth who helped with SBT.
+Overall, it was an intense 7 weeks for us as well as the course students. Organizing a MOOC is no small matter. We could count on the help the EPFL team, with Lukas Rytz, Nada Amin, Vojin Jovanovic and Manohar Jonnalagedda who designed and implemented the grading infrastructure, prepared the setup instructions, designed the homeworks, and edited the videos and quizzes; Tao Lee, who did most of the video cutting and editing, Tobias Schlatter, who worked tirelessly answering questions on the discussion boards, Pedro Pinto, who designed the recording equipment setup, and Nastaran Fatemi Odersky who did content editing. Many people at Typesafe also helped, in particular the IDE team around Iulian Dragos and Mirco Dotta who implemented the worksheet software and Josh Suereth who helped with sbt.
 
 Hard as the work of preparing and running the course was, the amount of positive feedback we got made it worth for us many times over. We believe this medium has a lot of potential and, so far, we are only scratching the surface.
 

overviews/macros/changelog211.md

@@ -29,7 +29,7 @@ Quasiquotes is the single most impressive upgrade for reflection and macros in S
 
 4) **[Type macros](http://docs.scala-lang.org/overviews/macros/typemacros.html) and [macro annotations](http://docs.scala-lang.org/overviews/macros/annotations.html)**. Neither type macros, not macro annotations are included of Scala 2.11.0. It is highly unlikely that type macros will ever be included in Scala, but we still deliberate on macro annotations. However, macro annotations are available both for Scala 2.10.x and for Scala 2.11.0 via the [macro paradise plugin](http://docs.scala-lang.org/overviews/macros/annotations.html).
 
-5) **@compileTimeOnly**. Standard library now features a new `scala.annotations.compileTimeOnly` annotation that tells scalac that its annottees should not be referred to after type checking (which includes macro expansion). The main use case for this annotation is marking helper methods that are only supposed be used only together with an enclosing macro call to indicate parts of arguments of that macro call that need special treatment (e.g. `await` in scala/async or `value` in SBT's new macro-based DSL). For example, scala/async's `await` marked as `@compileTimeOnly` only makes sense inside an `async { ... }` block that compiles it away during its transformation, and using it outside of `async` is a compile-time error thanks to the new annotation.
+5) **@compileTimeOnly**. Standard library now features a new `scala.annotations.compileTimeOnly` annotation that tells scalac that its annottees should not be referred to after type checking (which includes macro expansion). The main use case for this annotation is marking helper methods that are only supposed be used only together with an enclosing macro call to indicate parts of arguments of that macro call that need special treatment (e.g. `await` in scala/async or `value` in sbt's new macro-based DSL). For example, scala/async's `await` marked as `@compileTimeOnly` only makes sense inside an `async { ... }` block that compiles it away during its transformation, and using it outside of `async` is a compile-time error thanks to the new annotation.
 
 ### Changes to the macro engine
 

overviews/macros/overview.md

@@ -104,7 +104,7 @@ The call is expanded to the following reflective macro invocation
 ## A complete example
 
 This section provides an end-to-end implementation of a `printf` macro, which validates and applies the format string at compile-time.
-For the sake of simplicity the discussion uses console Scala compiler, but as explained below macros are also supported by Maven and SBT.
+For the sake of simplicity the discussion uses console Scala compiler, but as explained below macros are also supported by Maven and sbt.
 
 Writing a macro starts with a macro definition, which represents the facade of the macro.
 Macro definition is a normal function with anything one might fancy in its signature.
@@ -217,9 +217,9 @@ An important aspect of macrology is separate compilation. To perform macro expan
 
 This scenario is covered in the previous section. In short, compile macros and their usages using separate invocations of `scalac`, and everything should work fine. If you use REPL, then it's even better, because REPL processes every line in a separate compilation run, so you'll be able to define a macro and use it right away.
 
-### Using macros with Maven or SBT
+### Using macros with Maven or sbt
 
-The walkthrough in this guide uses the simplest possible command-line compilation, but macros also work with build tools such as Maven and SBT. Check out [https://github.com/scalamacros/sbt-example](https://github.com/scalamacros/sbt-example) or [https://github.com/scalamacros/maven-example](https://github.com/scalamacros/maven-example) for end-to-end examples, but in a nutshell you only need to know two things:
+The walkthrough in this guide uses the simplest possible command-line compilation, but macros also work with build tools such as Maven and sbt. Check out [https://github.com/scalamacros/sbt-example](https://github.com/scalamacros/sbt-example) or [https://github.com/scalamacros/maven-example](https://github.com/scalamacros/maven-example) for end-to-end examples, but in a nutshell you only need to know two things:
 * Macros needs scala-reflect.jar in library dependencies.
 * The separate compilation restriction requires macros to be placed in a separate project.
 

overviews/macros/paradise.md

@@ -39,7 +39,7 @@ Proceed to the [the feature list](/overviews/macros/roadmap.html) document for m
 
 Consult [https://github.com/scalamacros/sbt-example-paradise](https://github.com/scalamacros/sbt-example-paradise)
 for an end-to-end example, but in a nutshell working with macro paradise is as easy as adding the following two lines
-to your build (granted you’ve already [set up SBT](/overviews/macros/overview.html#using_macros_with_maven_or_sbt)
+to your build (granted you’ve already [set up sbt](/overviews/macros/overview.html#using_macros_with_maven_or_sbt)
 to use macros).
 
     resolvers += Resolver.sonatypeRepo("releases")

overviews/quasiquotes/setup.md

@@ -51,13 +51,13 @@ On the other side of spectrum there is also a `showRaw` pretty printer that show
 
 In Scala 2.10, quasiquotes are only available via the [macro paradise compiler plugin](http://docs.scala-lang.org/overviews/macros/paradise.html).
 
-In short, using quasiquotes in 2.10 is as simple as adding a single `addCompilerPlugin` line to your SBT build for the macro paradise plugin that enables quasiquotes and an additional `libraryDependencies` line for the supporting library that is necessary for quasiquotes to function in Scala 2.10. A full example is provided at [https://github.com/scalamacros/sbt-example-paradise](https://github.com/scalamacros/sbt-example-paradise).
+In short, using quasiquotes in 2.10 is as simple as adding a single `addCompilerPlugin` line to your sbt build for the macro paradise plugin that enables quasiquotes and an additional `libraryDependencies` line for the supporting library that is necessary for quasiquotes to function in Scala 2.10. A full example is provided at [https://github.com/scalamacros/sbt-example-paradise](https://github.com/scalamacros/sbt-example-paradise).
 
 New `showCode` pretty printer is not available under 2.10.
 
-## SBT cross-compile
+## sbt cross-compile
 
-Here's a neat SBT snippet taken from [Spire](https://github.com/non/spire) that allows you to use quasiquotes and cross-compile against both Scala 2.10 and 2.11:
+Here's a neat sbt snippet taken from [Spire](https://github.com/non/spire) that allows you to use quasiquotes and cross-compile against both Scala 2.10 and 2.11:
 
     libraryDependencies := {
       CrossVersion.partialVersion(scalaVersion.value) match {

overviews/reflection/thread-safety.md

@@ -47,10 +47,10 @@ It's much worse for runtime reflection though. Reflection init is called the fir
 and this initialization can happen in an indirect fashion. The most prominent example here is that calling methods with `TypeTag` context bounds
 is potentially problematic, because to call such a method Scala typically needs to construct an autogenerated type tag, which needs to create
 a type, which needs to initialize the reflective universe. A corollary is that if you don't take special measures, you can't call reliably
-use `TypeTag`-based methods in tests, because a lot of tools, e.g. SBT, run tests in parallel.
+use `TypeTag`-based methods in tests, because a lot of tools, e.g. sbt, run tests in parallel.
 
 Bottom line:
 * If you're writing a macro, which doesn't explicitly create threads, you're perfectly fine.
 * Runtime reflection mixed with threads or actors might be dangerous.
 * Multiple threads calling methods with `TypeTag` context bounds might lead to non-deterministic results.
-* Check out [SI-6240](https://issues.scala-lang.org/browse/SI-6240) to see our progress with this issue.
+* Check out [SI-6240](https://issues.scala-lang.org/browse/SI-6240) to see our progress with this issue.

sips/minutes/_posts/2016-07-15-sip-minutes.md

@@ -194,11 +194,11 @@ Jorge asks the SIP committee to provide  feedback to the authors to speed up the
 SLIP process in the future.
 
 * JSON AST: No news from the last discussion in the slip repo. It's been
-integrated into Play and SBT server 1.0. The committee considers that it's a
+integrated into Play and sbt server 1.0. The committee considers that it's a
 prime candidate for the platform.
 * Extensions of Futures and Promises: the committee calls for an implementation.
 This SLIP will be addressed by the next SLIP committee.
-* Either monadic bias: it was merged one day before by the Lightband team. Therefore, this SIP is both accepted and merged.
+* Either monadic bias: it was merged one day before by the Lightbend team. Therefore, this SIP is both accepted and merged.
 * scala.io.Target: Martin proposes to delay it until the SLIP committee decides
 how the platform would look like. Then, they will take care of it.
 * Redesigning collections views: Jorge explains what Josh, who is author of the

sips/pending/_posts/2017-01-13-binary-compatibility.md

@@ -79,12 +79,12 @@ the compiled artifacts could be used in both Dotty-compiled and Scalac-compiled
 In case there's a need to develop an API that will be used by clients compiled using different major versions of Scala, 
 the current approach is to either develop them in Java or to use best guess to restrict what Scala features should be used.
 
-There's also a different approach which is used by SBT: instead of publishing a binary `compiler-interface`, sources are published instead that would be locally compiled.
+There's also a different approach which is used by sbt: instead of publishing a binary `compiler-interface`, sources are published instead that would be locally compiled.
 
 Examples:
 
   1. Zinc\[[8]\] is writing their interfaces in Java because the interface has to be Scala version agnostic, as it is shipped in every sbt release, independently of Scala version that was used to compile zinc or will be used in to compile the project.
-SBT additionally compiles on demand the compiler bridge, which implements this Java interface. 
+sbt additionally compiles on demand the compiler bridge, which implements this Java interface. 
 
   2. Dotty\[[7]\] currently uses java defined interfaces as public API for IntelliJ in order to ensure binary compatibility. 
 These interfaces can be replaced by `@stableABI` annotated traits to reach the same goal.