To localize strftime() I need to sudo locale-gen on server

trellis
1

I’m in the process of migrating a pretty complex site to Trellis (finally). The last thing I need to tackle is localizing automated reminder ticket mails to users who ordered a trip via the site.

I use Polylang for localization. On the shared host I was on I had a cron running which set’s the users language by fetching it from the database and by running:

  • switch_to_locale(‘user_locale’)
  • setlocale(LC_ALL, ‘user_locale’)
  • load_plugin_textdomain(etc)

On the Trellis provisioned server (dev / staging) this doesn’t work. The automated mail will use the correct language strings, but will render dates in the default language.

They only way I’ve been able to fix this was by installing the language packs on the server via SSH. But it feels to me this isn’t the correct method to get this working. If it is, is there a way to automate this while provisioning?

Hope someone can point me in the right direction. Kind regards!

2

See discussion at Adding wp language files on deploy

1 Like
3

Thanks @ben! Thank you so much for your reply. I really appreciate it. I tried to search for an answer before posting but it never came to mind that the answer might lay in installing WP language packs via the CLI.

My site is already configured and deployed in Dutch and the WP language files are in my repo. This makes me wonder if installing languages via the CLI is redundant or does it do more than just downloading the *.mo files? From your reply I assume it also installs the locales as well? Is that correct?

4

Got this working by using the approach as suggested by @mockey. Thanks!

Might it make sense to implement this in Trellis core?

5

@roberto:
That’s nice to hear. I didn’t get much feedback on my suggestion otherwise.

IMO this definitely belongs into the core (as a configurable option, as I laid out).
There are some problems on first deploy (when wordpress is not installed yet) but I think @strarsis provided some fixes for that.
@ben: Are you interested in a core PR or would you rather see that as an extension?

1 Like
6

Hi @mockey. Thanks, I will check out that fix because I’m planning to deploy to production soon.

7

I’m indeed getting an error using your approach on first deploy. I have yet to find the fix in @starsis replies. This stuff is complicated. Learning so much :slight_smile:

8

@roberto: This is the approach I currently use for installing WordPress core and plugin languages:

The post also contains some extra tips, like fallback language and optimizing the download/update of language packages on each deploy.

9

Yes, but it should work on the second one.
I’ll get back to this next week and try to come up with a fixed version.
I also saw that wp-cli has changed, you have to update languages for themes and plugins separately now.

10

Why not use a shared folder for laanguages?

11

So sorry @starsis, I’m really having trouble following your post. It must be my limited knowledge in this matter. Thanks a lot for your reply though.

12

Cool, keep me posted :slight_smile: For now deploying two times after a fresh provision isn’t that much of a hassle.

13

Exactly this is done as the optimization :wink:

14

So you get an error when you deploy the first time?
I had the same issue when the WordPress site hadn’t been set up yet.
The WordPress site has to be set up first, this can also be done using wp,
then the language install commands are happy.

1 Like
15

@strarsis
Is project_copy_folders better than project_shared_children for languages?
Have to think about this …
BTW: Is there a way to test a first deploy without completely setting up a new server?

16

I am using this hook for ensuring WordPress is installed (generally on all sites that are deployed),
deploy-hooks/finalize-after.yml:

- name: Install WP (required for installing languages on non-transferred site)
  command: wp core {{ project.multisite.enabled | default(false) | ternary('multisite-install', 'install') }}
           --allow-root
           --url="{{ site_env.wp_home }}"
           {% if project.multisite.enabled | default(false) %}
           --base="{{ project.multisite.base_path | default('/') }}"
           --subdomains="{{ project.multisite.subdomains | default('false') }}"
           {% endif %}
           --title="{{ project.site_title | default(site) }}"
           --admin_user="{{ project.admin_user | default('admin') }}"
           --admin_password="{{ vault_wordpress_sites[site].admin_password }}"
           --admin_email="{{ project.admin_email }}"
  args:
    chdir: "{{ deploy_helper.current_path }}"
  register: wp_install
  changed_when: "'WordPress is already installed.' not in wp_install.stdout and 'The network already exists.' not in wp_install.stdout"
17

Currently I am using the project_copy_folders option:

# There are certain folders you'll want to copy from release to release to speed up deploys.
# Examples: Composer's `vendor` folder, npm's `node_modules`.
# These should not be part of project_shared_children since dependencies need to be atomic and tied to a deploy.
project_copy_folders:
  - vendor
  - web/app/languages

But when there is a better approach I would like to know.

18

Maybe it’s better than using project_shared_children. Not sure…