Add docs on custom attributes, custom settings, and user-defined attr…

…ibutes #1564 + Rename the doc `redevelopment` to `customization`

turms-docs/src/.vitepress/config.ts

@@ -95,8 +95,8 @@ export default defineConfig({
                                 text: 'Development',
                                 items: [
                                     {
-                                        text: 'About Secondary Development',
-                                        link: '/server/development/redevelopment.md'
+                                        text: 'About Custom Development',
+                                        link: '/server/development/customization.md'
                                     },
                                     {
                                         text: 'Basic Development Rules',
@@ -313,8 +313,8 @@ export default defineConfig({
                                 text: '开发',
                                 items: [
                                     {
-                                        text: '关于二次开发',
-                                        link: '/zh-CN/server/development/redevelopment.md'
+                                        text: '关于定制化开发',
+                                        link: '/zh-CN/server/development/customization.md'
                                     },
                                     {
                                         text: '基本开发规约',

turms-docs/src/client/turms-chat-demo.md

@@ -4,12 +4,12 @@
 
 Initially, our plan was to let users to reuse existing XMPP clients by making turms-gateway support the XMPP protocol. However, both paid and free XMPP clients have generally low quality, mainly due to the following reasons:
 
-1. Most XMPP client projects have poor code quality, especially early client engineers who lack coding skills. They often mix complex UI logic with business logic (e.g., the famous open-source project JMeter), making it difficult for redevelopment. It is better to rewrite them from scratch.
+1. Most XMPP client projects have poor code quality, especially early client engineers who lack coding skills. They often mix complex UI logic with business logic (e.g., the famous open-source project JMeter), making it difficult for customization. It is better to rewrite them from scratch.
 2. Both commercial and open-source XMPP clients have UI designs that are at an amateur level. If a client project lacks a professional UI, we doubt the capabilities of their frontend engineers and UI designers (a competent intermediate frontend engineer should be capable of designing a single product UI independently). We do not recommend users to adopt their solutions.
 3. There is hardly any open-source XMPP client that supports a complete cross-platform solution.
 4. Many low-quality XMPP clients even require payment.
 
-Considering that developing a cross-platform IM application is not difficult and mainly involves manual work, and that IM application UI and functionalities are highly generic (researching 10 commercial IM applications in the market would reveal that at least 9 of them have similar UI and functionalities), we decided to first provide the IM client demo `turms-chat-demo-flutter` for Turms users to use or redevelopment. We will support the XMPP protocol later.
+Considering that developing a cross-platform IM application is not difficult and mainly involves manual work, and that IM application UI and functionalities are highly generic (researching 10 commercial IM applications in the market would reveal that at least 9 of them have similar UI and functionalities), we decided to first provide the IM client demo `turms-chat-demo-flutter` for Turms users to use or customize. We will support the XMPP protocol later.
 
 ## Roadmap
 
@@ -30,13 +30,13 @@ We want to emphasize the term `demo` in the project name. This term mainly has t
 
 1. Whether from a product perspective or a technical perspective, this client "demo" is just one of the "possible" solutions. Users should not limit their ability to design their own IM products because of this "demo." Especially, do not assume that Turms' server is customized for this "demo." As repeatedly mentioned in the Turms documentation, Turms is a generic IM solution dedicated to solving various IM scenarios.
 2. Prepare for users' further development. This mainly involves three aspects:
-   1. Separation of UI and business logic. This allows teams that need to do redevelopment to reuse the UI to implement their own business logic. Readers can even use the `turms-chat-demo-flutter` project without the Turms server, but instead use their own self-developed IM server.
+   1. Separation of UI and business logic. This allows teams that need to customize to reuse the UI to implement their own business logic. Readers can even use the `turms-chat-demo-flutter` project without the Turms server, but instead use their own self-developed IM server.
    2. We continue to use the permissive Apache 2.0 license instead of the more restrictive GPL license commonly used in client open-source projects.
-   3. Since the UI design of IM applications worldwide is very similar, this `demo` will also implement most of the generic UI and logic for IM. It generally does not provide more customized logic to facilitate redevelopment by other teams.
+   3. Since the UI design of IM applications worldwide is very similar, this `demo` will also implement most of the generic UI and logic for IM. It generally does not provide more customized logic to facilitate customization by other teams.
 
 Note: `demo` does not imply "low quality." Readers will understand this by examining the code quality and UI design later.
 
-## Redevelopment
+## Custom Development
 
 Due to the numerous design patterns for Flutter applications, many applications lack a unified design, resulting in multiple conflicting designs within a single application, making the architecture look very chaotic.
 

turms-docs/src/community/index.md

@@ -90,15 +90,15 @@ For Turms, upstream first mainly involves two aspects: communication and code fe
 
   Note: Because of the complexity of requirements, many "seemingly" issues on GitHub Issues are in "pending". Many feature-related issues are just seeds that developers need to do more detailed requirement analysis, design, and coding, and the most difficult thing is usually requirement analysis, which needs to clarify "what needs to be done", and developers need to consider both current and future requirements, and prevent over-design. This is also why Turms documentation mentions several times that "the design and implementation of IM business functions are far more difficult than the design and implementation of technology middleware".
 
-* Reduce your maintenance costs and facilitate the continuous merging of upstream updates. If a developer forks the Turms project for complex secondary development, they will face a long-term maintenance problem: if the developer wants to use upstream's new code, they need to constantly adapt their own branch, and the faster upstream Turms server updates, the greater the developer's adaptation workload. There may even be logical conflicts that the developer is not aware of.
+* Reduce your maintenance costs and facilitate the continuous merging of upstream updates. If a developer forks the Turms project for complex custom development, they will face a long-term maintenance problem: if the developer wants to use upstream's new code, they need to constantly adapt their own branch, and the faster upstream Turms server updates, the greater the developer's adaptation workload. There may even be logical conflicts that the developer is not aware of.
 
   On the contrary, if developers give back the code to upstream, such problems will not occur. Because we will not only maintain these feedbacked codes together, but also consider whether these new designs and these feedbacked codes are consistent in design when designing other new related functional modules for Turms.
 
-* Reduce maintenance conflicts and avoid overturning local implementations repeatedly. Developers may have added some new features or fixed some bugs locally, but have not given back. After a period of time, developers may find that upstream considers the functionality they have implemented to be more thoughtful and complete, and the bug fixes are more ingenious (readers can read about the difficulty of Turms server-side bugs in [Task Difficulty](https://turms-im.github.io/docs/server/development/redevelopment#%E6%9C%8D%E5%8A%A1%E7%AB%AF)). Ultimately, developers have to revert all their original work, then re-pull upstream and start over again. The workload among them is painful to think about, and the more developers change locally, the more conflicts there may be.
+* Reduce maintenance conflicts and avoid overturning local implementations repeatedly. Developers may have added some new features or fixed some bugs locally, but have not given back. After a period of time, developers may find that upstream considers the functionality they have implemented to be more thoughtful and complete, and the bug fixes are more ingenious (readers can read about the difficulty of Turms server-side bugs in [Task Difficulty](https://turms-im.github.io/docs/server/development/customization#%E6%9C%8D%E5%8A%A1%E7%AB%AF)). Ultimately, developers have to revert all their original work, then re-pull upstream and start over again. The workload among them is painful to think about, and the more developers change locally, the more conflicts there may be.
 
 ### About Contacting Turms Author for Private Chat and Custom Development
 
-If readers' teams are interested in doing redevelopment themselves, they can directly refer to the article on [Redevelopment](https://turms-im.github.io/docs/en-US/server/development/redevelopment.html).
+If readers' teams are interested in doing custom development, they can directly refer to the article on [Custom Development](https://turms-im.github.io/docs/en-US/server/development/customization.html).
 
 For users who wish to pay Turms' author for custom development, it's worth noting that Turms' author generally only accepts unpaid development for common needs (yes, generally, only unpaid development for the community). The reason for this is quite simple; Turms' author doesn't lack money, and even if the Turms project incurs a loss of several tens of thousands of Chinese yuan every year, we can still ensure the continuous operation of the Turms project because we never intended to profit from it in the first place. So, either we will only accept a very high offer that's hard to refuse, or we will only accept unpaid development for the community.