Translate texts of 'recommendations.ts' from Russian to English

The content of the 'recommendations.ts' file in the translations folder has been translated from Russian to English. This involves updates to the descriptions of several recommendation variables, as well as modifying related key-value pairs to match the English language context.

src/ts/translations/en/recommendations.ts

@@ -1,506 +1,503 @@
 export default `
 § recommendations.title
-Рекомендации и факты
+Recommendations and Facts
 
 § recommendations.timestamp.firstCommit.description
-сделал первый коммит
+made the first commit
 
-День недели: $1
+Day of the Week: $1
 
 § recommendations.timestamp.lastCommit.description
-сделал последний коммит
+made the last commit
 
-День недели: $1
+Day of the Week: $1
 
-§ recommendations.timestamp.common.title: $1 дней
+§ recommendations.timestamp.common.title: $1 days
-§ recommendations.timestamp.allDays.description: от первого до последнего коммита (включая выходные и праздники).
+§ recommendations.timestamp.allDays.description: from the first to the last commit (including weekends and holidays).
-§ recommendations.timestamp.lossesDays.description: без коммитов, даже с учётом выходных, отпуска и государственных праздников.
+§ recommendations.timestamp.lossesDays.description: days without commits, even considering weekends, vacation, and public holidays.
 § recommendations.timestamp.weekendDays.description
-работы на выходных
+working on weekends
 
-# Почему это плохо:
+# Why this is bad:
-- заказчик платит двойную цену за работу в выходной день;
+- the client pays double the price for work on a weekend day;
-- сотрудники быстрее выгорают;
+- employees burn out faster;
 
-§ recommendations.timestamp.regularWeekendWord.title: Регулярные переработки
+§ recommendations.timestamp.regularWeekendWord.title: Regular Overtime
-§ recommendations.timestamp.sometimeWeekendWord.title: Бывают переработки
+§ recommendations.timestamp.sometimeWeekendWord.title: Occasional Overtime
 § recommendations.timestamp.weekendWord.description
-Вероятно, стоит сменить менеджера проекта, аналитика и архитектора.
+It might be advisable to change the project manager, analyst, and architect.
 
-# Почему это плохо:
+# Why this is bad:
-- заказчик платит двойную цену за работу в выходной день;
+- the client pays double the price for work on a weekend day;
-- качество продукта, как правило, получается низкое;
+- the quality of the product is usually low;
-- часть сотрудников увольняется;
+- some employees resign;
-- из-за спешки появляются новые ошибки;
+- new errors emerge due to the rush;
 
-# Скорее всего:
+# Most likely:
-- неверно оценили сроки в самом начале;
+- deadlines were incorrectly estimated at the beginning;
-- тех. задание отсутствует;
+- technical specifications are missing;
-- слабая аналитика;
+- weak analytics;
-- слабая архитектура (архитектора не нанимали, а команда состоит из мидл разработчиков);
+- weak architecture (no architect was hired, and the team consists of mid-level developers);
-- сначала начали писать код, потом проектировать;
+- started writing code first, then planning;
-- нет нормальных процессов, чтобы понять ошибки;
+- lack of proper processes to understand mistakes;
 
-§ recommendations.timestamp.neverWeekendWord.title: Обычно без переработок
+§ recommendations.timestamp.neverWeekendWord.title: Usually Without Overtime
 § recommendations.timestamp.neverWeekendWord.description
-Но иногда бывают.
+But sometimes it happens.
 
-# Почему это плохо:
+# Why this is bad:
-- заказчик платит двойную цену за работу в выходной день;
+- the client pays double the price for work on a weekend day;
-- сотрудники быстрее выгорают;
+- employees burn out faster;
 
 § recommendations.scope.parallelism.not.title
-Нет параллельных работ
+No Parallel Work
 
 § recommendations.scope.parallelism.not.description
-любую фичу в один момент времени делает один человек.
+any feature at any given time is done by one person.
 
-# Метод расчёта:
+# Calculation method:
-- человеко-дни делятся на фактические дни для каждой фичи;
+- person-days are divided by the actual days for each feature;
-- находим среднее арифметическое;
+- we find the arithmetic mean;
-- если результат меньше 1.3 считаем, что параллельных работ в рамках большинства фичей обычно нет;
+- if the result is less than 1.3, we consider that there is usually no parallel work within most features;
 
-# Почему это плохо:
+# Why this is bad:
-- повышается bus factor;
+- increases bus factor;
-- сотрудники медленнее развиваются;
+- employees develop more slowly;
-- трудно качественно проверить работу сотрудника;
+- difficult to properly check an employee's work;
 
-# Почему это хорошо:
+# Why this is good:
-- появляются эксперты, которые очень глубоко погружены в предметную область и могут предложить более качественные решения;
+- experts emerge who are deeply immersed in the subject area and can offer more quality solutions;
-- скорее всего не бывает merge конфликтов;
+- most likely there are no merge conflicts;
-- проект может очень быстро параллельно развиваться в разные стороны;
+- the project can quickly develop in different directions simultaneously;
 
 § recommendations.scope.parallelism.has.title
-Часть работ параллельно
+Some Work Done in Parallel
 
 § recommendations.scope.parallelism.has.description
-Иногда фичу делают одновременно несколько человек.
+Sometimes a feature is worked on simultaneously by several people.
-
-# Метод расчёта:
-- человеко-дни делятся на фактические дни для каждой фичи;
-- находим среднее арифметическое;
-- если результат от 1.3 до 2.0 считаем, что часть работ в рамках разных фичей иногда делается параллельно;
 
+# Calculation method:
+- person-days are divided by the actual days for each feature;
+- we find the arithmetic mean;
+- if the result is from 1.3 to 2.0, we consider that some of the work within different features is sometimes done in parallel;
 
 § recommendations.scope.parallelism.every.title
-Параллельные работы
+Parallel Work
 
 § recommendations.scope.parallelism.every.description
-любую фичу в один момент времени делают несколько человек
+any feature at any given time is worked on by several people
-
-# Метод расчёта:
-- человеко-дни делятся на фактические дни для каждой фичи;
-- находим среднее арифметическое;
-- если результат больше двух считаем, что большая часть работ в рамках разных фичей обычно делается параллельно;
 
+# Calculation method:
+- person-days are divided by the actual days for each feature;
+- we find the arithmetic mean;
+- if the result is more than two, we consider that most of the work within different features is usually done in parallel;
 
 § recommendations.scope.money
-в такую сумму можно оценить работу по данному проекту.
+this is the estimated cost for the work on this project.
 
-# Метод расчёта:
+# Calculation method:
-- человеко-дни затраченные на разработку умножаются на индивидуальную зарплату разработчиков;
+- person-days spent on development are multiplied by the individual salaries of the developers;
 
-Изменить зарплату каждого разработчика, для более точной суммы, можно в разделе «Настройки»
+To change the salary of each developer for a more accurate total, go to the "Settings" section.
 
-# Это много или мало?
+# Is this too much or too little?
-Для ответа на этот вопрос, нужно ответить на следующие:
+To answer this question, consider the following:
-- Можно ли за эти деньги было купить готовое решение?
+- Could a ready-made solution have been purchased for this amount of money?
-- Можно ли за эти деньги сделать более хороший продукт?
+- Could a better product have been developed for this amount of money?
 
-Если ответ на оба вопроса «да», то возможно, разработка с нуля не стоила потраченных на неё денег.
+If the answer to both questions is "yes," then perhaps developing from scratch was not worth the money spent.
  
 § recommendations.scope.bus.everyHasOne.title
 Bus factor = 1
 
 § recommendations.scope.bus.everyHasOne.description
-В большинство фич погружен один человек.
+Most features are deeply understood by only one person.
-Надо переключать людей.
+It's necessary to rotate people.
 
-# Почему это плохо:
+# Why this is bad:
-- если сотрудники будут увольняться, будет трудно продолжить их работу;
+- if employees resign, it will be difficult to continue their work;
-- невозможно контролировать качество его кода;
+- it’s impossible to control the quality of their code;
 
-# Как делается выборка:
+# How the sample is chosen:
-- более 80% коммитов в фичу делает один человек;
+- more than 80% of commits in a feature are made by one person;
-- проект имеет более 60% таких фичей;
+- the project has more than 60% of such features;
 
 § recommendations.scope.bus.oneMaintainer
-в фичи погружен один человек.
+one person is deeply involved in a feature.
 
-# Почему это плохо:
+# Why this is bad:
-- если он уволится, будет трудно продолжить разработку;
+- if they resign, it will be hard to continue development;
-- снижается качество code-review;
+- the quality of code-review decreases;
-- трудно запараллелить разработку при необходимости;
+- it’s difficult to parallelize development when needed;
 
-# Как делается выборка:
+# How the sample is chosen:
-- более 80% коммитов в фичу сделал один человек;
+- more than 80% of commits in a feature are made by one person;
 
 § recommendations.scope.types.process.title
-Плохие процессы
+Poor Processes
 
 § recommendations.scope.types.process.description
-Большинство фич содержат один тип задач.
+Most features contain one type of task.
 
 § recommendations.scope.types.one
-фичи содержат один тип задач.
+features contain one type of task.
 
 § recommendations.scope.types.common
-Возможно, разработчики неправильно подписывают коммиты или менеджер заводит один и тот же тип задач.
+It's possible that developers are incorrectly signing commits or the manager is entering the same type of tasks.
 
-# Почему это важно:
+# Why this is important:
-- невозможно передать поддержку другой команде;
+- it's impossible to hand over support to another team;
-- невозможно выпустить "коробочную" версию;
+- it's impossible to release a "boxed" version;
-- сильная зависимость от конкретных разработчиков;
+- strong dependence on specific developers;
-- большое количество ошибок и низкое качество кода;
+- a high number of errors and low code quality;
-- вероятное замедление разработки в будущем;
+- potential slowdown in development in the future;
 
-# В чём ошибка менеджера:
+# The manager's mistake:
-- взгляд на продукт, только с позиции «работающей демки»;
+- viewing the product only from the perspective of a "working demo";
 
-# Что должно быть:
+# What should be done:
-- тесты;
+- tests;
-- ошибки (выявленные по результатам тестов);
+- bugs (identified through testing);
-- рефакторинг (т.к. архитектура может измениться);
+- refactoring (as architecture may change);
-- документация;
+- documentation;
-- правки стиля (как результат опроса фокус-группы);
+- style revisions (as a result of focus group feedback);
 
 § recommendations.scope.plan.title
-Постройте долгосрочный план
+Develop a Long-Term Plan
 
 § recommendations.scope.plan.description
-с учетом архитектуры.
+taking architecture into account.
 
-При том опираться этот план должен сразу на самые трудные задачи.
+This plan should immediately focus on the most challenging tasks.
 
-# Почему отсутствие плана плохо:
+# Why the lack of a plan is bad:
-- сотрудники делают минимально работающую версию, не закладывая точки расширения. После этого пишется не масштабируемый код, который тормозит следующие фичи;
+- employees create a minimally viable version without planning for expansion points. After this, unscalable code is written, which slows down future features;
 
-# В чём ошибка менеджера:
+# The manager's mistake:
-- он не показал, как продукт будет развиваться далее и в каких точках будет рост;
+- they haven't shown how the product will develop further and where the growth points will be;
 
-# Как должно быть:
+# How it should be done:
-- составляется глобальный план развития продукта;
+- a global product development plan is created;
-- составляется глобальный план развития архитектуры (с разработчиками и DBA);
+- a global architecture development plan is created (with developers and DBAs);
-- на уровне схем сразу проговариваются моменты, которые могут сильно измениться;
+- potential significant changes are discussed upfront at the schematic level;
 
 § recommendations.scope.cost.title
-Оцените инвестиции в фичу
+Evaluate Investment in a Feature
 
 § recommendations.scope.cost.description
-с количеством потенциальной прибыли.
+in terms of potential profit.
 
-Фичи которые дорого стоят в разработке, но приносят мало прибыли, возможно, стоит отложить или вообще отменить. Это сделает проект более коммерчески успешным.
+Features that are expensive to develop but bring little profit may need to be postponed or even canceled. This will make the project more commercially successful.
 
 § recommendations.author.lotOfLazy
-пишет слишком мало кода.
+writes too little code.
 
-# Может уволить?
+# Should they be fired?
-- он тимлид, архитектор, аналитик?
+- are they a team leader, architect, or analyst?
-- это его основной проект?
+- is this their primary project?
-- есть какие-то зависимости от него?
+- are there any dependencies on them?
 
-# Почему нет смысла исправлять
+# Why it makes no sense to correct
-Суммарные затраты на разработчика уже больше чем прибыль от его работы.
+The total costs for the developer are already more than the profit from their work.
-Если мы считаем, что объективных помех его работе не было, то человек либо не хочет работать вообще, либо работает на двух проектах одновременно.
+If we believe that there were no objective hindrances to their work, then the person either does not want to work at all or is working on two projects simultaneously.
-Увольнение и замена новым сотрудником выглядит оправданным с точки зрения общей статистики.
+Firing and replacing them with a new employee seems justified from a statistical point of view.
 
 § recommendations.author.manyLazy
-пишет мало кода. Нужно взять на контроль.
+writes little code. Needs to be monitored.
 
-# Как делается выборка:
+# How the sample is chosen:
-- на тестовых выборках хороший программист пишет код больше 80% времени;
+- in test samples, a good programmer writes code for more than 80% of the time;
-- в данном случае показатель от 60% до 80%;
+- in this case, the indicator is between 60% and 80%;
 
-# Как контролировать:
+# How to monitor:
-- дробить задачи на 1..2 дня;
+- break tasks into 1..2 days;
-- каждый день спрашивать статус;
+- ask for a status update every day;
-- убедиться, что задачи хорошо расписаны и готовы к началу разработки;
+- ensure tasks are well defined and ready for development;
-- устроить парное программирование, чтобы проверить фактическую скорость;
+- arrange pair programming to check actual speed;
 
 § recommendations.author.oneTypeMans
-получает слишком однообразные задачи по типу. Может выгореть.
+receives too many monotonous tasks of the same type. Risk of burnout.
 
-# Почему это важно:
+# Why this is important:
-- если сотрудник выгорит, его скорость работы снизится;
+- if an employee burns out, their work speed will decrease;
-- замедляется профессиональный рост;
+- professional growth slows down;
-- повышается вероятность увольнения;
+- the likelihood of resignation increases;
 
-# Как делается выборка:
+# How the sample is chosen:
-- для каждого коммита определятся тип задачи;
+- the type of task is determined for each commit;
-- если больше 70% задач одного типа, значит человек делает одно и тоже;
+- if more than 70% of tasks are of the same type, it means the person is doing the same thing repeatedly;
 
-§ recommendations.author.workToday.title: Работает $1
+§ recommendations.author.workToday.title: Working $1
 § recommendations.author.workToday.description
-над проектом в данный момент.
+on the project at this moment.
 
-# Состав: 
+# Composition: 
 - $1;
 
-# Почему именно они:
+# Why specifically them:
-- рабочих дней более 50%;
+- more than 50% of workdays;
-- работали в течении последних 30 дней;
+- have worked during the last 30 days;
 
-§ recommendations.author.dismissed.title: Уволилось $1
+§ recommendations.author.dismissed.title: Dismissed $1
 § recommendations.author.dismissed.description
-или работало короткий промежуток времени.
+or worked for a short period.
 
-# Состав:
+# Composition:
 - $1;
 
-# Почему именно они:
+# Why specifically them:
-- работали в нормальном ритме (видимо, это их основной репозиторий);
+- worked at a normal pace (apparently, this is their main repository);
-- за последний месяц не было ни одного коммита;
+- no commits in the last month;
-- отпуск обычно 14 дней (их отсутствие не похоже на отпуск);
+- vacation usually lasts 14 days (their absence does not resemble a vacation);
 
-§ recommendations.author.staff.title: Помогают $1
+§ recommendations.author.staff.title: Assisting $1
 § recommendations.author.staff.description
-Люди другой специализации, которые что-либо коммитили.
+People of other specializations who have committed something.
 
-# Состав: 
+# Composition: 
 - $1;
 
-# Почему именно они:
+# Why specifically them:
-- это не open-source проект;
+- this is not an open-source project;
-- рабочих дней менее 15% от общего числа;
+- workdays less than 15% of the total number;
-- изменяют примерно одни и те же файлы;
+- modify roughly the same files;
 
 § recommendations.author.projectType.openSource.title
-Открытый проект
+Open Project
 
 § recommendations.author.projectType.openSource.description
-пять дней в неделю тут не работают.
+they do not work five days a week here.
 
-Проект может быть и закрытым, просто такой темп работы обычно у открытых библиотек на GitHub.
+The project may be closed, but this work pace is typical for open libraries on GitHub.
 
-# Метод оценки:
+# Assessment method:
-- берется статистика по всем активным разработчикам;
+- statistics are taken for all active developers;
-- подсчитывается среднее число дней работы и без коммитов;
+- the average number of working days and days without commits is calculated;
-- у open-source библиотек рабочих дней обычно максимум 15..20%;
+- for open-source libraries, working days are usually a maximum of 15..20%;
 
-# Последствия
+# Consequences
-Для проектов, где работа не постоянна, нет смысла во многих показателях. Поэтому показатели без коммитов, скорости и т.п. будут скрыты.
+For projects where work is not constant, many indicators do not make sense. Therefore, indicators like days without commits, speed, etc., will be hidden.
-
-Как правило, оценку таких проектов делают перед началом разработки своей закрытой версии. Самые интересные показатели в этом случае вероятная стоимость и суммарное время на разработку.
 
+Typically, such projects are assessed before starting the development of their own closed version. The most interesting indicators in this case are the probable cost and total development time.
 
 § recommendations.author.projectType.easy.title
-Слабая загрузка
+Light Workload
 
 § recommendations.author.projectType.easy.description
-слишком много дней без коммитов. Нужно понять почему команда не пишет код.
+too many days without commits. It is necessary to understand why the team is not writing code.
 
-# Метод оценки:
+# Assessment method:
-- берется статистика по всем активным разработчикам;
+- take statistics from all active developers;
-- подсчитывается среднее число дней работы и без коммитов;
+- calculate the average number of working days and days without commits;
-- загрузка считается слабой, если процент без коммитов от 5% до 20%;
+- workload is considered light if the percentage of days without commits is between 5% and 20%;
 
-# Возможные причины:
+# Possible reasons:
-- фактически нет задач;
+- there are actually no tasks;
-- задачи есть, но хорошо ложатся на текущую архитектуру;
+- there are tasks, but they fit well with the current architecture;
-- разработчиков отвлекают совещаниями;
+- developers are distracted by meetings;
-- команда не работает;
+- the team is not working;
 
-# Варианты решения:
+# Solutions:
-- обсудить проблему с командой;
+- discuss the issue with the team;
-- уменьшить гранулярность задач, чтобы за день можно было успеть сделать одну или две задачи;
+- reduce task granularity so that one or two tasks can be completed in a day;
-- ввести ежедневные совещания, чтобы проверять движение задач по статусу;
+- introduce daily meetings to check the status of tasks;
-- устроить сеансы парного программирования, чтобы убедиться, что разработчик может работать быстрее;
+- arrange pair programming sessions to ensure that the developer can work faster;
 
 § recommendations.author.manager.title
-Обозначьте дедлайны
+Set Deadlines
 
 § recommendations.author.manager.description
-У любой задачи должен быть чёткий дедлайн.
+Every task should have a clear deadline.
  
-Это позволит не затягивать её выполнение на несколько дней или недель.
+This will prevent dragging out its completion for several days or weeks.
 
-# Какие показатели стоит проверить:
+# Indicators to check:
-- количество дней на одну задачу, которое тратит работник;
+- the number of days spent on one task by an employee;
-- количество дней ожидания влития PR (страница статистики по PR);
+- the number of days waiting for PR merge (PR statistics page);
 
 § recommendations.author.shorTalk.title
-Проводите ежедневные совещания
+Conduct Daily Meetings
 
 § recommendations.author.shorTalk.description
-они помогают быть в курсе проекта.
+they help stay informed about the project.
  
-Не растягивайте их отвлекаясь на посторонние темы.
+Do not stretch them by getting sidetracked on irrelevant topics.
 
-# На какие вопросы должен ответить сотрудник:
+# Questions the employee should answer:
-- что было сделано;
+- what was done;
-- что будет сделано;
+- what will be done;
-- есть ли какие-либо проблемы;
+- are there any issues;
 
-# Следует обрывать монолог, если:
+# Interruptions should occur if:
-- начинают подробно описывать мелкие детали, которые не важны;
+- they start describing minor details in-depth, which are not important;
-- уводят диалог в сторону, от первоначального плана;
+- they steer the conversation away from the original plan;
 
-# Почему это важно:
+# Why this is important:
-Часто сотрудник, который ничего не делает, старается уйти от ответа. Для этого он рассказывает кучу ненужных подробностей свой работы. Это позволяет усыпить внимание участников и растянуть время ответа. Создается ощущение что он чем-то занят, хотя по факту работы не было.
+Often an employee who does nothing tries to avoid the answer by telling a bunch of unnecessary details of their work. This lulls the participants' attention and stretches the time for a response. It creates an impression that they are busy, even though there was no actual work done.
 
 § recommendations.author.ipr.title
-Составьте план обучения
+Develop a Training Plan
 
 § recommendations.author.ipr.description
-на каждого сотрудника.
+for each employee.
 
-*Индивидуальный план обучения* — это список целей и задач, которые помогают человеку развиваться в определенной области.
+*Individual training plan* is a list of goals and tasks that help a person develop in a certain area.
 
-# Как составить план:
+# How to create a plan:
-- составить матрицу компетенций;
+- create a competency matrix;
-- определить по каким компетенциям меньше всего знаний и опыта;
+- identify which competencies have the least knowledge and experience;
-- узнать какие из этих компетенций интересны сотруднику;
+- find out which of these competencies are of interest to the employee;
-- придумать 3..5 целей в рамках каждой такой компетенции на полпостороние года или год;
+- come up with 3..5 goals within each such competency for the next six months or a year;
-- каждый месяц пытаться сделать что-либо для достижения одной цели;
+- try to do something every month to achieve one goal;
-- каждый месяц напоминать об общем плане достижения этих целей;
+- remind every month about the overall plan to achieve these goals;
 
-# Нужен ли план руководителю?
+# Does a manager need a plan?
-Да, руководитель так же должен составить план на себя. Если нет вышестоящего руководителя, то он должен проверять сам себя.
+Yes, the manager should also make a plan for themselves. If there is no higher-level manager, they should self-assess.
 
-# Почему это важно:
+# Why this is important:
-- сотрудники становятся более лояльны к компании;
+- employees become more loyal to the company;
-- за теже деньги вы получаете более квалифицированные кадры;
+- you get more qualified personnel for the same money;
 
 § recommendations.author.oneToOne.title
-Проводите 1-1 каждый месяц
+Conduct One-on-One Meetings Every Month
 
 § recommendations.author.oneToOne.description
-это поможет выявить проблемы на ранней стадии.
+it helps to identify problems at an early stage.
 
-*One-to-one* — это регулярные личные встречи руководителя с подчиненным. На таких встречах обычно обсуждают всё, что важно для сотрудника, что его волнует, и то, чем он может поделиться с руководителем только наедине.
+*One-to-one* is a regular personal meeting of a manager with a subordinate. Such meetings typically discuss everything important to the employee, what concerns them, and what they can share with the manager in private.
 
-# Почему это важно:
+# Why this is important:
-- легко выяснить, кто из сотрудников перегружен, а у кого есть свободное время;
+- easy to find out who is overburdened and who has free time;
-- можно предотвратить выгорание сотрудника;
+- possible to prevent employee burnout;
-- можно получить быструю обратную связь о процессах, которые вы можете не замечать;
+- quick feedback can be obtained about processes that you might not notice;
-- формируется доверительное отношение, сотрудники становятся более лояльны к компании;
+- trust is built, making employees more loyal to the company;
-- повышается мотивация и вовлеченность сотрудников;
+- increases employee motivation and engagement;
 
 § recommendations.author.club.title
-Ходите в бар
+Go to a Bar
 
 § recommendations.author.club.description
-один раз в месяц или два.
+once a month or two.
 
-Это поможет выстроить неформальную коммуникацию в коллективе и сплотить команду, даже если общение будет сжатым.
+This will help build informal communication within the team and bring the team together, even if the interaction is brief.
 
-# Почему это важно:
+# Why this is important:
-- можно получить быструю обратную связь о процессах, которые вы можете не замечать;
+- quick feedback can be obtained about processes that you might not notice;
-- формируется доверительное отношение, сотрудники становятся более лояльны к компании;
+- trust is built, making employees more loyal to the company;
-- повышается вовлеченность сотрудников;
+- increases employee engagement;
 
-§ recommendations.hour.onlyWork.title: Выходных тут нет
+§ recommendations.hour.onlyWork.title: No Weekends Here
-§ recommendations.hour.onlyWork.description: Вероятно, стоит уволить менеджера проекта.
+§ recommendations.hour.onlyWork.description: The project manager should probably be fired.
-§ recommendations.hour.weekends.title: Работа на выходных
+§ recommendations.hour.weekends.title: Working on Weekends
-§ recommendations.hour.weekends.description: Вероятно, стоит проверить менеджера проекта.
+§ recommendations.hour.weekends.description: The project manager should probably be checked.
-§ recommendations.hour.easy.title: Бывают проблемы
+§ recommendations.hour.easy.title: There Are Problems
-§ recommendations.hour.easy.description: Вероятно, бывают завалы и приходится работать на выходных.
+§ recommendations.hour.easy.description: There are likely crunch times and work is needed on weekends.
-§ recommendations.week.lazyDays.down.title: Стало меньше прогулов
+§ recommendations.week.lazyDays.down.title: Fewer Absences
-§ recommendations.week.lazyDays.down.description: за последние три недели этот показатель упал
+§ recommendations.week.lazyDays.down.description: this indicator has dropped over the last three weeks
-§ recommendations.week.lazyDays.up.title: Стало больше прогулов
+§ recommendations.week.lazyDays.up.title: More Absences
-§ recommendations.week.lazyDays.up.description: нет задач или нужен более жесткий контроль
+§ recommendations.week.lazyDays.up.description: no tasks or stricter control is needed
-§ recommendations.week.notWork.title: Стабильно не дорабатывает
+§ recommendations.week.notWork.title: Consistently Underperforms
-§ recommendations.week.notWork.description: т.к. каждую неделю пишет код не 100% времени
+§ recommendations.week.notWork.description: as every week the code is not 100% of the time
-§ recommendations.week.upWork.title: Стабильно перерабатывает
+§ recommendations.week.upWork.title: Consistently Overworks
-§ recommendations.week.upWork.description: т.к. каждую неделю пишет код в выходные дни
+§ recommendations.week.upWork.description: as every week code is written on weekend days
-§ recommendations.week.task.up.title: Растёт производительность
+§ recommendations.week.task.up.title: Productivity is growing
-§ recommendations.week.task.up.description: или задачи стали слишком мелкие. Нужно проверить. Если гранулярность та же - закрепить результат.
+§ recommendations.week.task.up.description: or tasks have become too small. Need to check. If granularity is the same - reinforce the result.
-§ recommendations.week.task.lazyMaintainer.description: стабильный лидер по прогулам. Уволить?
+§ recommendations.week.task.lazyMaintainer.description: consistently leads in absences. Fire?
-§ recommendations.week.task.down.title: Падает производительность
+§ recommendations.week.task.down.title: Productivity is Falling
 § recommendations.week.task.down.description
-или задачи хуже разбивают. Нужно проверить. Если гранулярность та же - взять на контроль.
+or tasks are poorly split. Need to check. If granularity is the same - take control.
 
-# Метод оценки:
+# Assessment method:
-- количество задач в день, над которыми работают, на протяжении последних трех недель стабильно падает.
+- the number of tasks per day that are being worked on has been steadily decreasing over the last three weeks.
 
-# Возможные ошибки:
+# Possible errors:
-- задачи могли быть сложнее, чем казались;
+- tasks could have been more complex than they seemed;
-- задачи могли иметь большой объём работы (нужно проверить количество изменений, падают они или нет за этот же период)
+- tasks could have had a large volume of work (need to check if the number of changes is also decreasing during this period)
 
-§ recommendations.type.everyHasOne.title: Не подписывают тип задачи
+§ recommendations.type.everyHasOne.title: Not Signing Task Types
-§ recommendations.type.everyHasOne.description: большинство типов задач делает один человек.
+§ recommendations.type.everyHasOne.description: Most task types are done by one person.
-§ recommendations.type.oneMaintainer.title: Узкая специализация
+§ recommendations.type.oneMaintainer.title: Narrow Specialization
 § recommendations.type.oneMaintainer.description
-большинство задач одного типа делают одни и те же люди.
+most tasks of one type are done by the same people.
 
-# Типы задач:
+# Task types:
 
 § recommendations.type.common
-# Возможно, это не так
+# It might not be the case
 
-Нужно убедиться, что остальные сотрудники верно подписывают коммиты.
+Make sure that other employees correctly sign commits.
 
-Шаги, которые помогут это сделать:
+Steps to ensure this:
-- настроить пре-коммит проверку для commit message;
+- set up a pre-commit check for commit messages;
-- объяснить команде, что нужно указывать тип;
+- explain to the team the need to indicate the type;
-- проверить в новых ветках, что сотрудники следуют правилу;
+- check in new branches that employees follow this rule;
 
-# Если это действительно так
+# If it is indeed the case
 
-Вы настроили проверки и убедились что один и тот же сотрудник, делает задачи одного и того же типа.
+You have set up checks and ensured that the same employee does tasks of the same type.
 
-Почему это плохо:
+Why this is bad:
-- его увольнение остановит целую пачку процессов;
+- their resignation will halt a whole bunch of processes;
-- уменьшается компетенция остальных членов команды;
+- it reduces the competence of other team members;
-- трудно верхнеуровнево понять его правки;
+- difficult to understand their edits at a higher level;
 
-Как это исправить:
+How to fix this:
-- распределять разные типы задач равномерно;
+- distribute different types of tasks evenly;
-- менять область работы (тесты, документация, ошибки) между сотрудниками через спринт;
+- change the area of work (tests, documentation, bugs) among employees every sprint;
 
 § recommendations.type.fewTypes.title
-Это локальный продукт
+This is a Local Product
 
 § recommendations.type.fewTypes.description
-для конкретного заказчика или проблемы.
+for a specific customer or problem.
 
-# Какие признаки есть у «глобального» продукта:
+# Signs of a "global" product:
-- локализация;
+- localization;
-- документация;
+- documentation;
-- большой объём тестов;
+- a large volume of tests;
-- визуальная кастомизация;
+- visual customization;
-- рефакторинг узких мест;
+- refactoring of bottlenecks;
-- и т.п.
+- etc.
 
-# Почему этот продукт выглядит как «локальный»:
+# Why this product looks like a "local" one:
-- у каждого «глобального» признака будет перевес по своему типу задач;
+- each "global" sign will be outweighed by its type of task;
-- чем больше «глобальных» признаков, тем больше вероятность «глобального» продукта;
+- the more "global" signs, the more likely a "global" product;
 
-В данном случае мы видим небольшое число типов, а следовательно, скорее всего есть недоработки, мешающие легко масштабировать продукт на мировой рынок и продавать его в других странах.
+In this case, we see a small number of types, which likely indicates shortcomings that prevent the product from being easily scaled to the global market and sold in other countries.
 
-# Возможно, это не так
+# It might not be the case
-По типам файлов мы можем предположить тип программы (сайт, серверное приложение, DevOps скрипты и т.д.). Для frontend приложения наша гипотеза будет более верной, чем для DevOps-скриптов, которые могут быть лишь микро-модулем инициализации.
+Based on file types, we can assume the type of program (website, server application, DevOps scripts, etc.). For a frontend application, our hypothesis will be more accurate than for DevOps scripts, which might just be a micro-module of initialization.
 
 § recommendations.type.diff.title
-Разбейте лидирующий тип на подтипы
+Break Down the Leading Type into Subtypes
 
 § recommendations.type.diff.description
-для детализации ошибок.
+to detail errors.
 
-Как правило, тип задач с меткой «исправление ошибок» является лидирующим. Это делает статистику слабо-детализированной.
+Typically, the task type labeled "bug fixing" is leading. This makes the statistics weakly detailed.
 
-*Если у вас произошла такая ситуация*, вы можете разбить этот тип на подтипы (например, по месту обнаружения).
+*If you encounter this situation*, you can break down this type into subtypes (e.g., based on the location of detection).
 
-Рассмотрим несколько вариантов подтипов:
+Consider several options for subtypes:
-- fix_dev (ошибка выявленная в процессе разработки);
+- fix_dev (error detected during development);
-- fix_test (ошибка выявленная в процессе тестирования);
+- fix_test (error detected during testing);
-- fix (ошибка выявленная в проде);
+- fix (error detected in production);
 
 § recommendations.type.buddy.title
-Копите мелкие задачи
+Accumulate Minor Tasks
 
 § recommendations.type.buddy.description
-для новых сотрудников.
+for new employees.
 
-# Если задача:
+# If a task is:
-- не важная;
+- not important;
-- не большая;
+- not big;
-- не требует сильного погружения в контекст;
+- doesn't require deep immersion in the context;
-- больше про рефакторинг, чем про новый код;
+- more about refactoring than new code;
 
-# Положите её в backlog с меткой «для новичков».
+# Put it in the backlog with the label "for beginners".
 
-Когда придёт новый сотрудник, вы сможете моментально достать ему пачку небольших и разнообразных по типу задач, для ознакомления с проектом.
+When a new employee arrives, you will be able to immediately pull out a bunch of small and varied tasks for them to get acquainted with the project.
 
-Также, если у вас будет застой в работе, вы сможете доставать по одной такой мелкой задаче из backlog-а.
+Also, if you have a lull in work, you can pull out one such minor task from the backlog.
 `;