[WIP] Add initial Portuguese (pt) i18n setup (UI strings only)

astro.config.mjs

@@ -137,6 +137,10 @@ export default defineConfig({
                 zh: {
                     label: "中文",
                 },
+                pt: {
+                    label: "Português",
+                    lang: "pt"
+                }
             },
             social: [
                 {

src/content/docs/pt/docs/about/alternatives.mdx

@@ -0,0 +1,139 @@
+---
+title: Alternatives
+sidebar:
+  order: 3
+  badge:
+    text: WIP
+    variant: caution
+---
+
+import { FileTree } from '@astrojs/starlight/components';
+
+History of architecture approaches
+
+## Big Ball of Mud
+
+> What is it; Why is it so common; When it starts to bring problems; What to do and how does FSD help in this
+
+- [(Article) Oleg Isonen - Last words on UI architecture before an AI takes over](https://oleg008.medium.com/last-words-on-ui-architecture-before-an-ai-takes-over-468c78f18f0d)
+- [(Report) Julia Nikolaeva, iSpring - Big Ball of Mud and other problems of the monolith, we have handled](http://youtu.be/gna4Ynz1YNI)
+- [(Article) DD - Big Ball of mud](https://thedomaindrivendesign.io/big-ball-of-mud/)
+
+
+## Smart & Dumb components
+
+> About the approach; About applicability in the frontend; Methodology position
+
+About obsolescence, about a new view from the methodology
+
+Why component-containers approach is evil?
+
+- [(Article) Den Abramov-Presentation and Container Components (TLDR: deprecated)](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
+
+
+## Design Principles
+
+> What are we talking about; FSD position
+
+SOLID, GRASP, KISS, YAGNI, ... - and why they don't work well together in practice
+
+And how does it aggregate these practices
+
+- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Design Principles)](https://youtu.be/SnzPAr_FJ7w?t=380)
+
+
+## DDD
+
+> About the approach; Why does it work poorly in practice
+
+What is the difference, how does it improve applicability, where does it adopt practices
+
+- [(Article) DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
+- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Clean Architecture, DDD)](https://youtu.be/SnzPAr_FJ7w?t=528)
+
+
+## Clean Architecture
+
+> About the approach; About applicability in the frontend; FSD position
+
+How are they similar (to many), how are they different
+
+- [(Thread) About use-case/interactor in the methodology](https://t.me/feature_sliced/3897)
+- [(Thread) About DI in the methodology](https://t.me/feature_sliced/4592)
+- [(Article) Alex Bespoyasov - Clean Architecture on frontend](https://bespoyasov.me/blog/clean-architecture-on-frontend/)
+- [(Article) DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
+- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Clean Architecture, DDD)](https://youtu.be/SnzPAr_FJ7w?t=528)
+- [(Article) Misconceptions of Clean Architecture](http://habr.com/ru/company/mobileup/blog/335382/)
+
+
+## Frameworks
+
+> About applicability in the frontend; Why frameworks do not solve problems; why there is no single approach; FSD position
+
+Framework-agnostic, conventional-approach
+
+- [(Article) About the reasons for creating the methodology (fragment about frameworks)](/docs/about/motivation)
+- [(Thread) About the applicability of the methodology for different frameworks](https://t.me/feature_sliced/3867)
+
+
+## Atomic Design
+
+### What is it?
+In Atomic Design, the scope of responsibility is divided into standardized layers.
+
+Atomic Design is broken down into **5 layers** (from top to bottom):
+
+1. `pages` - Functionality similar to the `pages` layer in FSD.
+2. `templates` - Components that define the structure of a page without tying to specific content.
+3. `organisms` - Modules consisting of molecules that have business logic.
+4. `molecules` - More complex components that generally do not contain business logic.
+5. `atoms` - UI components without business logic.
+
+Modules at one layer interact only with modules in the layers below, similar to FSD.
+That is, molecules are built from atoms, organisms from molecules, templates from organisms, and pages from templates.
+Atomic Design also implies the use of Public API within modules for isolation.
+
+### Applicability to frontend
+
+Atomic Design is relatively common in projects. Atomic Design is more popular among web designers than in development.
+Web designers often use Atomic Design to create scalable and easily maintainable designs.
+In development, Atomic Design is often mixed with other architectural methodologies.
+
+However, since Atomic Design focuses on UI components and their composition, a problem arises with implementing
+business logic within the architecture.
+
+The problem is that Atomic Design does not provide a clear level of responsibility for business logic,
+leading to its distribution across various components and levels, complicating maintenance and testing.
+The business logic becomes blurred, making it difficult to clearly separate responsibilities and rendering
+the code less modular and reusable.
+
+### How does it relate to FSD?
+
+In the context of FSD, some elements of Atomic Design can be applied to create flexible and scalable UI components.
+The `atoms` and `molecules` layers can be implemented in `shared/ui` in FSD, simplifying the reuse and
+maintenance of basic UI elements.
+
+<FileTree>
+- shared/
+  - ui/
+    - atoms/
+    - molecules/
+</FileTree>
+
+A comparison of FSD and Atomic Design shows that both methodologies strive for modularity and reusability
+but focus on different aspects. Atomic Design is oriented towards visual components and their composition.
+FSD focuses on dividing the application's functionality into independent modules and their interconnections.
+
+- [Atomic Design Methodology](https://atomicdesign.bradfrost.com/table-of-contents/)
+- [(Thread) About applicability in shared / ui](https://t.me/feature_sliced/1653)
+- [(Video) Briefly about Atomic Design](https://youtu.be/Yi-A20x2dcA)
+- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Atomic Design)](https://youtu.be/SnzPAr_FJ7w?t=587)
+
+## Feature Driven
+
+> About the approach; About applicability in the frontend; FSD position
+
+About compatibility, historical development and comparison
+
+- [(Talk) Oleg Isonen - Feature Driven Architecture](https://youtu.be/BWAeYuWFHhs)
+- [Feature Driven-Short specification (from the point of view of FSD)](https://github.com/feature-sliced/documentation/tree/rc/feature-driven)

src/content/docs/pt/docs/about/mission.mdx

@@ -0,0 +1,51 @@
+---
+title: Mission
+sidebar:
+  order: 1
+---
+
+Here we describe the goals and limitations of the applicability of the methodology-which we are guided by when developing the methodology
+
+- We see our goal as a balance between ideology and simplicity
+- We won't be able to make a silver bullet that fits everyone
+
+**Nevertheless, the methodology should be close and accessible to a fairly wide range of developers**
+
+## Goals
+
+### Intuitive clarity for a wide range of developers
+
+The methodology should be accessible - for most of the team in projects
+
+*Because even with all the future tools , it will not be enough, if only experienced seniors/leads will understand the methodology*
+
+### Solving everyday problems
+
+The methodology should set out the reasons and solutions to our everyday problems when developing projects
+
+**And also-attach tools to all this (cli, linters)**
+
+So that developers can use a *battle-tested* approach that allows them to bypass long-standing problems of architecture and development
+
+> *@sergeysova: Imagine, that a developer writes code within the framework of the methodology and he has problems 10 times less often, simply because other people have thought out the solution to many problems.*
+
+## Limitations
+
+We do not want to *impose our point of view*, and at the same time we understand that *many of our habits, as developers, interfere from day to day*
+
+Everyone has their own level of experience in designing and developing systems, **therefore, it is worth understanding the following:**
+
+- **Will not work**: very simple, very clear, for everyone
+    > *@sergeysova: Some concepts cannot be intuitively understood until you encounter problems and spend years solving them.*
+    >
+    > - *In math world: is graph theory.*
+    > - *In physics: quantum mechanics.*
+    > - *In programming: application architecture.*
+
+- **Possible and desirable**: simplicity, extensibility
+
+## See also
+
+- [Architecture problems][refs-architecture--problems]
+
+[refs-architecture--problems]: /docs/about/understanding/architecture#problems

src/content/docs/pt/docs/about/motivation.mdx

@@ -0,0 +1,149 @@
+---
+title: Motivation
+sidebar:
+  order: 2
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+The main idea of **Feature-Sliced Design** is to facilitate and reduce the cost of developing complex and developing projects, based on [combining research results, discussing the experience of various kinds of a wide range of developers][ext-discussions].
+
+Obviously, this will not be a silver bullet, and of course, the methodology will have its own [limits of applicability][refs-mission].
+
+Nevertheless, there are reasonable questions regarding *the feasibility of such a methodology as a whole*
+
+<Aside>
+
+More details [discussed in the discussion][disc-src]
+
+</Aside>
+
+## Why are there not enough existing solutions?
+> It usually, these arguments:
+>
+> - *"Why you need some new methodology, if you already have long-established approaches and principles of design such as `SOLID`, `KISS`, `YAGNI`, `DDD`, `GRASP`, `DRY`, etc."*
+> - *"All the problems are solved by good project documentation, tests, and structured processes"*
+> - *"Problems would not have happened if all developers are following all the above"*
+> - *"Everything was invented before you, you just can't use it"*
+> - *"Take \{FRAMEWORK_NAME\} - everything has already been decided for you there"*
+
+### Principles alone are not enough
+
+**The existence of principles alone is not enough to design a good architecture**
+
+Not everyone knows them completely, even fewer understand and apply them correctly
+
+*The design principles are too general, and do not give a specific answer to the question: "How to design the structure and architecture of a scalable and flexible application?"*
+
+### Processes don't always work
+
+*Documentation/Tests/Processes* are, of course, good, but alas, even at high costs for them - **they do not always solve the problems posed by the architecture and the introduction of new people into the project**
+
+- The time of entry of each developer into the project is not greatly reduced, because the documentation will most often come out huge / outdated
+- Constantly make sure that everyone understands architecture in the same way-it also requires a huge amount of resources
+- Do not forget about the bus-factor
+
+### Existing frameworks cannot be applied everywhere
+
+- Existing solutions usually have a high entry threshold, which makes it difficult to find new developers
+- Also, most often, the choice of technology has already been determined before the onset of serious problems in the project, and therefore you need to be able to "work with what is" - **without being tied to the technology**
+
+> Q: *"In my project `React/Vue/Redux/Effector/Mobx/{YOUR_TECH}` - how can I better build the structure of entities and the relationships between them?"*
+
+### As a result
+
+We get *"unique as snowflakes"* projects, each of which requires a long immersion of the employee, and knowledge that is unlikely to be applicable on another project
+
+> @sergeysova: *"This is exactly the situation that currently exists in our field of frontend development: each lead will invent different architectures and project structures, while it is not a fact that these structures will pass the test of time, as a result, a maximum of two people can develop the project besides him, and each new developer needs to be immersed again."*
+
+## Why do developers need the methodology?
+
+### Focus on business features, not on architecture problems
+
+The methodology allows you to save resources on designing a scalable and flexible architecture, instead directing the attention of developers to the development of the main functionality. At the same time, the architectural solutions themselves are standardized from project to project.
+
+*A separate question is that the methodology should earn the trust of the community, so that another developer can get acquainted with it and rely on it in solving the problems of his project within the time available to him*
+
+### An experience-proven solution
+
+The methodology is designed for developers who are aimed at *a proven solution for designing complex business logic*
+
+*However, it is clear that the methodology is generally about a set of best-practices, articles that address certain problems and cases during development. Therefore, the methodology will also be useful for the rest of the developers-who somehow face problems during development and design*
+
+### Project Health
+
+The methodology will allow *to solve and track the problems of the project in advance, without requiring a huge amount of resources*
+
+**Most often, technical debt accumulates and accumulates over time, and the responsibility for its resolution lies on both the lead and the team**
+
+The methodology will allow you to *warn* possible problems in the scaling and development of the project in advance
+
+## Why does a business need a methodology?
+
+### Fast onboarding
+
+With the methodology, you can hire a person to the project who **is already previously familiar with this approach, and not train again**
+
+*People start to understand and benefit the project faster, and there are additional guarantees to find people for the next iterations of the project*
+
+### An experience-proven solution
+
+With the methodology, the business will get *a solution for most of the issues that arise during the development of systems*
+
+Since most often a business wants to get a framework / solution that would solve the lion's share of problems during the development of the project
+
+### Applicability for different stages of the project
+
+The methodology can benefit the project *both at the stage of project support and development, and at the MVP stage*
+
+Yes, the most important thing for MVP is *"features, not the architecture laid down for the future"*. But even in conditions of limited deadlines, knowing the best-practices from the methodology, you can *"do with little blood"*, when designing the MVP version of the system, finding a reasonable compromise
+(rather than modeling features "at random")
+
+*The same can be said about testing*
+
+## When is our methodology not needed?
+
+- If the project will live for a short time
+- If the project does not need a supported architecture
+- If the business does not perceive the connection between the code base and the speed of feature delivery
+- If it is more important for the business to close orders as soon as possible, without further support
+
+### Business Size
+
+- **Small business** - most often needs a ready-made and very fast solution. Only when the business grows (at least to almost average), he understands that in order for customers to continue using, it is necessary, among other things, to devote time to the quality and stability of the solutions being developed
+- **Medium-sized business** - usually understands all the problems of development, and even if it is necessary to *"arrange a race for features"*, he still spends time on quality improvements, refactoring and tests (and of course-on an extensible architecture)
+- **Big business** - usually already has an extensive audience, staff, and a much more extensive set of its practices, and probably even its own approach to architecture, so the idea of taking someone else's comes to them not so often
+
+## Plans
+
+The main part of the goals [is set out here][refs-mission--goals], but in addition, it is worth talking about our expectations from the methodology in the future
+
+### Combining experience
+
+Now we are trying to combine all our diverse experience of the `core-team`, and get a methodology hardened by practice as a result
+
+Of course, we can get Angular 3.0 as a result, but it is much more important here to **investigate the very problem of designing the architecture of complex systems**
+
+*And yes - we have complaints about the current version of the methodology, but we want to work together to come to a single and optimal solution (taking into account, among other things, the experience of the community)*
+
+### Life outside the specification
+
+If everything goes well, then the methodology will not be limited only to the specification and the toolkit
+
+- Perhaps there will be reports, articles
+- There may be `CODE_MODEs` for migrations to other technologies of projects written according to the methodology
+- It is possible that as a result we will be able to reach the maintainers of large technological solutions
+  - *Especially for React, compared to other frameworks - this is the main problem, because it does not say how to solve certain problems*
+
+## See also
+
+- [(Discussion) Don't need a methodology?][disc-src]
+- [About the methodology's mission: goals and limitations][refs-mission]
+- [Types of knowledge in the project][refs-knowledge]
+
+[refs-mission]: /docs/about/mission
+[refs-mission--goals]: /docs/about/mission#goals
+[refs-knowledge]: /docs/about/understanding/knowledge-types
+
+[disc-src]: https://github.com/feature-sliced/documentation/discussions/27
+[ext-discussions]: https://github.com/feature-sliced/documentation/discussions

src/content/docs/pt/docs/about/promote/for-company.mdx

@@ -0,0 +1,16 @@
+---
+title: Promote in company
+sidebar:
+  order: 4
+  badge:
+    text: WIP
+    variant: caution
+---
+
+## Do the project and the company need a methodology?
+
+> About the justification of the application, Those duty
+
+## How can I submit a methodology to a business?
+
+## How to prepare and justify a plan to move to the methodology?

src/content/docs/pt/docs/about/promote/for-team.mdx

@@ -0,0 +1,16 @@
+---
+title: Promote in team
+sidebar:
+  order: 3
+  badge:
+    text: WIP
+    variant: caution
+---
+
+- Onboard newcomers
+- Development Guidelines ("where to search N module", etc...)
+- New approach for tasks
+
+## See also
+- [(Thread) The simplicity of the old approaches and the importance of mindfulness](https://t.me/feature_sliced/3360)
+- [(Thread) About the convenience of searching by layers](https://t.me/feature_sliced/1918)