-
Notifications
You must be signed in to change notification settings - Fork 2
Add localizations update on post-deploy script #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Considering the move we're making towards in-theme translation, it'd be nice to have the `locale:update` included in post-deployment script, is already added on multiple major projects of ours
Have we ever not used the i18n setup via Note that what you suggest slows down each deploy by a couple of minutes, this should be better handled with a nightly cron job instead, or also a CI/CD schedule which syncs the configuration translations. IMHO the |
@esolitos we can skip |
The difference is minor. That being said: i don't think a nightly translation update is enough. When I work on a multilingual site and get the translations from the client, I will add them right away to the .po file of the corresponding custom module or theme and want to have the strings available immediately after I deployed it. Otherwise the customer will complain: "But what's with the Norwegian translation". |
Here's the wodby deployment log for a site, using that approach. I replaced the custom modules/themes with |
Did I understand correctly that |
Yes, you can make .po files in your module behave like a Drupal translation server. Sounds like a ramday session. I introduced a paradigm quite a while back for translations in custom themes and modules :D That would go into mymodule.info.yml.
Works also for themes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is rather useful given the last @szeidler feedback.
I really do not like the additional time we add on the post-deployment script, but I guess there's no really workaround to this, and comes with the benefit that we always get the updated translations on deploy, so overall it is likely a positive outcome.
Perfect, @szeidler if you also approve the PR, could we merge and close? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to handle the case where drupal is not installed yet (first deploy) and when Locale is not installed.
|
||
- name: Update localizations | ||
type: command | ||
command: drush locale:check && drush locale:update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have experienced an issue with this. It breaks if the locale
module is not installed and on the first deploys.
We need to add contingency for those two cases before we can merge it for all sites.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, @esolitos do you have any suggestions/workaround for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Post deployment step also needs to work if locale is not installed.
@szeidler if we don't have any solution for this, we can close this PR |
There is a solution, just not implemented :P |
Since we have been using the method on some sites I noticed the following: During the last few months I see that the deployment gets quite a big hit, when using the command on websites with a lot of contrib modules. The reason is, that the localization server responds relatively slow to our requests from Wodby. Considering that the majority of deploys do not include any localization updates we maybe should keep it as an opt-in setting like now? |
Considering the move we're making towards in-theme translation, it'd be nice to have the
locale:update
included in post-deployment script, is already added on multiple major projects of ours