Translation files aren’t loaded via symlink outside wordpress project directory

Files are not detected in what situation exactly?

You say “Translation files aren’t loaded”. Where are they located? What part of the system is doing the loading?

Please provide steps to reproduce and test.

Steps:
1. Install core wordpress using wp-cli or by downloading
2. Install demo database
3. Go to activated theme directory and move languages dir to below public_html, basically outside webroot directory. In my case:
core setup: /home/user/current/web/app/themes/twentynineteen
language dir: /home/user/shared/web/app/themes/twentynineteen/languages
4. ln -s /home/user/shared/web/app/themes/twentynineteen/languages /home/user/current/web/app/themes/twentynineteen
5. Add extra languages to wordpress setup
6. Install Greek language for the theme. I think this is one of the supported languages at least theme description lists it:

Arabic
Chinese
Cyrillic
Devanagari
Greek
Gujarati
Hebrew
Japanese
Korean
Thai

7. Go to theme translation via Loco Translate and you’ll see no languages and files listed.

Or you can do it otherwise fist install languages them move languages directory to symlink destination directory.

Basically I’m deploying project with mina deployment script and I can create symlinks to files which are translated or modified on production, so its basically translations. And if I copy content from symlink to languages2 directory remove symlink and mv languages2 languages, it starts to show them again.

• This reply was modified 5 years, 9 months ago by juslintek.
• This reply was modified 5 years, 9 months ago by juslintek.

Before I go ahead and set all this up…

Language files should not be installed under the theme. i.e. themes/twentynineteen/languages is a legacy location no longer included in WordPress downloads. Installed language packs will be found at: languages/themes/twentynineteen-*

Does this change anything? Do you get the same results when you symlink the installed languages directory?

But what if I would like to VCS languages? Whats the strategy for languages Version Control? I’ll move translations there. I think it doesn’t matter where languages are located after this:

load_theme_textdomain('my_textdomain', get_template_directory() . '/languages');

is used inside after_setup_theme, action hook callback.

• This reply was modified 5 years, 9 months ago by juslintek.
• This reply was modified 5 years, 9 months ago by juslintek.

I can’t offer advice on that part. load_theme_textdomain is part of WordPress. I’m trying to establishing if there’s a bug in my plugin, regarding your point no.7 above.

It’s possible that the file listing isn’t symlink safe, so I’ll look at that shortly. However, it would save me some time if you could eliminate the fact that the themes/twentynineteen/languages would not be expected to contain any files after a language install.

the languages directory should contain translation files.

Okay, so lets say just move whole wp-content/languages directory via symlink to parallel shared directory. As well I will try to adjust my code accordingly, that it would use new updated localization directory structure.

• This reply was modified 5 years, 9 months ago by juslintek.
• This reply was modified 5 years, 9 months ago by juslintek.

I’ve tested this. From a clean WordPress install, I installed Greek translations.

With the original folder structure (under /site) I have:

/site/wp-content/languages/themes/twentynineteen-el.mo

So as mentioned previously, nothing under themes/twentynineteen/languages as is normal.

Then I move the whole global languages directory to a shared location and symlink it into the site, as you suggest:

mv /site/wp-content/languages /shared/languages
ln -s /shared/languages /site/wp-content/languages

Then I go into Loco Translate dashboard and see warnings that /shared/languages is outside my open_basedir. So I fix that in my PHP config and restart server.

After this, file listings and translation loading all works as expected.

As for your original report –

Translation files aren’t loaded via symlink outside wordpress project directory

– I’m unable to reproduce this.

Perhaps you have the open_basedir issue too. Or perhaps some other file permission problem. All I can say is that Loco Translate can pull file listings from the normal registered paths as long as PHP can see the files.

@timwhitlock no, because I do same with uploads directory and cache directory and its working, its loco translate problem specifically, its just not loading languages on interface, while translations themselves are picked up by wordpress itself. Seems like you’re not using official WordPress FileSystem class to CRUD po, mo, pot files. P.S. I use no openbase dir restrictions as its not shared hosting.

• This reply was modified 5 years, 9 months ago by juslintek.
• This reply was modified 5 years, 9 months ago by juslintek. Reason: Forgot to mention openbase_dir restriction is not enabled

FileSystem abstraction isn’t necessary for reading files. WordPress itself doesn’t even use these classes for file listings.

You are also comparing the reading of files to the reading of directories. WordPress loading MO files for a given path is not equivalent to Loco Translate finding them inside your folders.

Let’s get back to reproducing why the file listings are failing …

Loco Translate deliberately avoids following symlinks in some situations (security reasons; avoiding infinite loops; avoiding scanning your entire server). It’s possible this applies in your case, but it shouldn’t apply to the official file locations like the languages directory. This measure is only taken when searching for additional files in non-standard locations.

In trying to reproduce your setup, clearly something is different. We started talking about a folder under your theme (themes/twentynineteen/languages) and are now talking about symlinking the entire wp-content/languages directory. Can you please show me your current setup and which points along the path are symlinked?

@timwhitlock, okay my current setup uses symlinked directory specified by this function:
Add this to after_theme_setup hooks callback in functions.php of twentynineteen:

load_theme_textdomain('tudosobresites', get_template_directory() . '/languages');

So you can just add this function to twentynineteen and move its language files from wp-content/languages/themes/twentynineteen* to wp-content/themes/twentynineteen/languages and then run this bash script to rename language files accordingly. Go to default wp ABSPATH directory and:

parallel_dir=$(realpath ../shared/wp-content/themes/twentynineteen/languages)
theme_dir=$(pwd)/wp-content/themes/twentynineteen
mkdir -p $paralel_dir
cp -rf wp-content/languages/themes/twentynineteen* $parallel_dir
cd $parallel_dir
for file in $(ls *.po *.mo); do mv $file $(echo $file | cut -d'-' -f2); done;
cd $theme_dir
ln -s $parallel_dir languages

And try it now.

P.S. I’ve currently change my CI environment just to copy language files on deployment from previous release to the current to avoid all that symlink stuff.

If this doesn’t work then guess its because I’m using bedrock then.

• This reply was modified 5 years, 9 months ago by juslintek.

OK, I’ve got it.

The issue is that when finding a file with no text domain prefix the path is checked to see if it is under the theme directory. Code here.

I could potentially fix that, but it’s a real edge case. Each folder in the path would have to be checked until one is found to be linked into the sub tree. Considering this folder location is deprecated, I’m not super keen to do that work.

I strongly recommend you don’t use folders under the theme to hold your translation files. As suggested earlier I suggest symlinking the global languages directory.

If you must use the theme folder, I suggest symlinking the entire theme rather than just its languages directory.

Okay I’ll do the rework.

I’ve added a fix for this in the dev branch.

The file finder still follows symlinks, but this code checks if the file was originally under the theme.

Thanx for the change, maybe it will be implemented in the future. But one way or another I think custom language directories should be considered. ?? Because I might save them in ABSPATH or even above public_html path. So people could access them lets say from more then one service. ??