Closed lindamacdonald closed 2 years ago
Just putting my two cents... As a developer who only submits issues and occassional PRs. Dashboard is currently coded in a way, in which it does not support multiple languages. So currently translations aren't an easy thing and the best thing to do is to fork the dashboard module and add the translations yourself without merging them with the codebase.
Or extend the Dashboard module to support i18n-like language changes...
Since I am not part of the core team, I cannot hereby say whether it is planned with v2 revision of Factor as well.
What pattern would you recommend for V2?
On Fri, Feb 12, 2021 at 7:10 AM bppdddqqqq notifications@github.com wrote:
Just putting my two cents... As a developer who only submits issues and occassional PRs. Dashboard is currently coded in a way, in which it does not support multiple languages. So currently translations aren't an easy thing and the best thing to do is to fork the dashboard module and add the translations yourself without merging them with the codebase.
Or extend the Dashboard module to support i18n-like language changes...
Since I am not part of the core team, I cannot hereby say whether it is planned with v2 revision of Factor as well.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fiction-com/factor/issues/259#issuecomment-778251351, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLHJSXJ4HKHP4E7S2PQMDS6VAETANCNFSM4XEQBQUA .
-- Founder @ Fiction.com
Primarily, the dashboard needs to embed all text into factor-settings.ts
The most obvious solutions that I can think of are two.
factor-settings.ts
to support translated setting files (say factor-settings.en_US.ts
, which will replace all defined settings in factor-settings.ts
under condition, the language is set to en_US
, so if key is defined in en_US, it uses that instead of the one in base file, but if the key is not defined in en_US, it defaults back to main file). This is extremely similar to i18n specification. Depending whether the installation is mono-lingual or multi-lingual has a "difficulty" to develop such feature. Mono-lingual can be easily rewritten, multilingual would require more than a simple modification in the build routine...I don't have any other ideas, I am merely basing myself off the experience I have with Java, that I also use at work 😅
Like any good architecture, enable hook to transform text: by language, context or by a11y (additional text for reader). Hooks run in Drupal, Wordpress and Prestashop and are key to success for this project too :) Any "override" is problematic in module level as this duplicate efford to translate same text over and over again. I think that hook can be used in may more scenario in future - text can be changed in live according of change as well according setting or to check spelling (new module on top of that hook)
Reason for this issue Hey there :) great project!! I had a browse through the docs and it said to fork a repo in case we wanted to contribute. I would like to contribute with a norwegian translation in case you don't already have one for the dashboard?
Steps to Reproduce