diff --git a/abp_io/AbpIoLocalization/AbpIoLocalization/Www/Localization/Resources/en.json b/abp_io/AbpIoLocalization/AbpIoLocalization/Www/Localization/Resources/en.json
index e1402ae8f2..c176776431 100644
--- a/abp_io/AbpIoLocalization/AbpIoLocalization/Www/Localization/Resources/en.json
+++ b/abp_io/AbpIoLocalization/AbpIoLocalization/Www/Localization/Resources/en.json
@@ -1624,7 +1624,7 @@
     "IntegratingTo3rdPartyLibrariesAndSystems_ABPSOLUTION_Description": "For example, ABP's RabbitMQ Distributed Event Bus integration abstracts all these details. You send and receive messages without the hustle and bustle. Do you need to write low-level code? No problem, you can always do that. ABP doesn't restrict you when you need to use low-level features of the library you are using.",
     "WhyNotBuildYourOwnFramework?": "Why Not Build Your Own Framework?",
     "WhyNotBuildYourOwnFramework_THEPROBLEM_Description": "All the infrastructure, even in the simplest way, takes a lot of time to build, maintain and document. It gets bigger over time, and it becomes hard to maintain it in your solution. Separating these into a re-usable project is the starting point for building your own internal framework.",
-    "WhyNotBuildYourOwnFramework_THEPROBLEM_Description2": "Building, documenting, training and maintaining an internal framework is really hard. If you don't have an experienced, dedicated framework team, your internal framework rapidly becomes an undocumented legacy code that no one can understand and maintain anymore. On the other hand, these frameworks are generally developed by one or two developers in the team. And these fellows are becoming a knowledge silo. It is good for them but bad for the company because they are the project's single point of failure <a href=\"https://en.wikipedia.org/wiki/Single_point_of_failure\">-SPOF-</a>. Once they leave the company, the project dramatically goes down.",
+    "WhyNotBuildYourOwnFramework_THEPROBLEM_Description2": "Building, documenting, training and maintaining an internal framework is really hard. If you don't have an experienced, dedicated framework team, your internal framework rapidly becomes an undocumented legacy code that no one can understand and maintain anymore. On the other hand, these frameworks are generally developed by one or two developers in the team. And these fellows are becoming a knowledge silo. It is good for them but bad for the company because they are the project's single point of failure <a href=\"https://en.wikipedia.org/wiki/Single_point_of_failure\" target=\"_blank\">-SPOF-</a>. Once they leave the company, the project dramatically goes down.",
     "WhyNotBuildYourOwnFramework_ABPSOLUTION_Description": "ABP is a community-driven, well-documented, mature and generic application framework. A team of highly experienced developers are working hard to keep it up-to-date, easy to understand and comfortable to use. Using such a stable framework makes you focus on your own business code and get help with the framework from experts whenever you need it.",
     "ArchitecturalInfrastructure_Description": "SaaS applications, modular or microservice systems are most used enterprise software models. Building such systems not only requires a good understanding and experience but also requires a strong software infrastructure. Otherwise, you will find yourself spending a great effort to support these architectural details in your codebase.",
     "Modularity_THEPROBLEM_Description": "Building a truly modular system is not easy! All the aspects of the system (database, entities, APIs, UI pages/components) can be split into modules, and each module can be re-usable without others. The plain ASP.NET Core doesn't provide such a modular architecture. If you need it, you should think about it from scratch.",