merging all conflicts

content/community/conferences.md

@@ -25,7 +25,7 @@ February 27 & 28, 2020 in Sydney, Australia
 ### ReactConf Japan 2020 {#reactconfjp-2020}
 March 21, 2020 in Tokyo, Japan
 
-[Website](https://reactconf.jp/) - [Twitter](https://twitter.com/reactjapanconf)
+[Website](https://reactconf.jp/) - [Twitter](https://twitter.com/reactjp)
 
 ### Reactathon 2020 {#reactathon-2020}
 March 30 - 31, 2020 in San Francisco, CA

content/docs/concurrent-mode-patterns.md

@@ -507,7 +507,7 @@ function ProfileTrivia({ resource }) {
 
 **[Try it on CodeSandbox](https://codesandbox.io/s/focused-mountain-uhkzg)**
 
-If you press "Open Profile" now, you can tell something is wrong. It takes whole seven seconds to make the transition now! This is because our trivia API is too slow. Let's say we can't make the API faster. How can we improve the user experience with this constraint?
+If you press "Open Profile" now, you can tell something is wrong. It takes a whole seven seconds to make the transition now! This is because our trivia API is too slow. Let's say we can't make the API faster. How can we improve the user experience with this constraint?
 
 If we don't want to stay in the Pending state for too long, our first instinct might be to set `timeoutMs` in `useTransition` to something smaller, like `3000`. You can try this [here](https://codesandbox.io/s/practical-kowalevski-kpjg4). This lets us escape the prolonged Pending state, but we still don't have anything useful to show!
 

content/docs/reconciliation.md

@@ -141,7 +141,11 @@ React будет мутировать каждого потомка, вмест
 
 При использовании ключей перестановки так же могут вызывать проблемы с состоянием компонента. Экземпляры компонента обновляются и повторно используются на основе их ключей. Перемещение элемента изменяет его, если ключ является индексом. В результате состояние компонента для таких вещей, как неуправляемые `<input>`, может смешаться и обновиться неожиданным образом.
 
+<<<<<<< HEAD
 [Здесь](codepen://reconciliation/index-used-as-key) на CodePen есть примеры проблем, которые могут быть вызваны использованием индексов в качестве ключей, а [здесь](codepen://reconciliation/no-index-used-as-key) обновлённая версия того же примера, которая показывает как проблемы с перестановкой, сортировкой и вставкой элементов в начало решаются, если не использовать индексы как ключи.
+=======
+Here is [an example of the issues that can be caused by using indexes as keys](codepen://reconciliation/index-used-as-key) on CodePen, and here is [an updated version of the same example showing how not using indexes as keys will fix these reordering, sorting, and prepending issues](codepen://reconciliation/no-index-used-as-key).
+>>>>>>> 821e20726266bc8113353d0c2b6d885f82e584a8
 
 ## Компромиссы {#tradeoffs}
 

content/docs/rendering-elements.md

@@ -70,6 +70,10 @@ React DOM сравнивает элемент и его дочернее дер
 
 ![В DOM видно частичное обновление](../images/docs/granular-dom-updates.gif)
 
+<<<<<<< HEAD
 Несмотря на то, что мы создаём элемент, описывающий всё UI-дерево, каждую секунду React DOM изменяет только текстовый узел, содержимое которого изменилось.
+=======
+Even though we create an element describing the whole UI tree on every tick, only the text node whose contents have changed gets updated by React DOM.
+>>>>>>> 821e20726266bc8113353d0c2b6d885f82e584a8
 
 Проще описать, как интерфейс выглядит в конкретный момент, чем как он изменяется с течением времени. По нашему опыту, такой подход позволяет избавиться от целого класса ошибок.

content/docs/strict-mode.md

@@ -32,7 +32,11 @@ permalink: docs/strict-mode.html
 
 ![](../images/blog/strict-mode-unsafe-lifecycles-warning.png)
 
+<<<<<<< HEAD
 Если избавиться от проблем, выявленных в строгом режиме, _уже сегодня_, то это позволит получить все преимущества асинхронного рендеринга в будущих релизах React.
+=======
+Addressing the issues identified by strict mode _now_ will make it easier for you to take advantage of concurrent rendering in future releases of React.
+>>>>>>> 821e20726266bc8113353d0c2b6d885f82e584a8
 
 ### Предупреждение об использовании устаревшего API строковых реф {#warning-about-legacy-string-ref-api-usage}
 
@@ -83,7 +87,11 @@ React работает в два этапа:
 * **Этап рендеринга (render phase)** определяет, какие изменения необходимо произвести, например, в DOM. В течение этого этапа React вызывает `render`, а затем сравнивает полученный результат с результатом предыдущего рендера.
 * **Этап фиксации (commit phase)** – в нём React применяет любые изменения. В случае React DOM – это этап, когда React вставляет, обновляет и удаляет DOM-узлы. В течение этого этапа React вызывает методы жизненного цикла `componentDidMount` и `componentDidUpdate`.
 
+<<<<<<< HEAD
 Этап фиксации обычно не занимает много времени, что нельзя сказать про этап рендеринга. По этой причине, готовящийся асинхронный режим (который по умолчанию ещё не включён) делит работу на части, периодически останавливает и возобновляет работу, чтобы избежать блокировки браузера. Это означает, что на этапе рендеринга React может вызвать методы жизненного цикла более чем один раз перед фиксацией, либо вызвать их без фиксации (из-за возникновения ошибки или прерывания с большим приоритетом).
+=======
+The commit phase is usually very fast, but rendering can be slow. For this reason, the upcoming concurrent mode (which is not enabled by default yet) breaks the rendering work into pieces, pausing and resuming the work to avoid blocking the browser. This means that React may invoke render phase lifecycles more than once before committing, or it may invoke them without committing at all (because of an error or a higher priority interruption).
+>>>>>>> 821e20726266bc8113353d0c2b6d885f82e584a8
 
 Этап рендеринга включает в себя следующие методы жизненного цикла:
 * `constructor`