Navigation Menu

Skip to content
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

Jump to bottom

Language Caching makes it a little harder to support translation tools (Trac #4620) #4620

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 7 comments
Closed

Language Caching makes it a little harder to support translation tools (Trac #4620) #4620

elgg-gitbot opened this issue Feb 16, 2013 · 7 comments
Assignees
@cash
Labels
engine

Comments

@elgg-gitbot
Copy link

Original ticket http://trac.elgg.org/ticket/4620 on 42480618-03-23 by trac user fmestrone, assigned to unknown.

Elgg version: 1.8.6

I have noticed that once language translations have been loaded for the first time and cached, the language_paths variables in $CONFIG is not reset in subsequent requests and will only contain the top level languages directory, but none of the plug-in ones.

While this is not a problem for the running of the site as such, it means that there is no easy way to get access to a list of all translation files and even a list of all available localisation within the product installation. This breaks the behaviour of certain plug-ins like the translation_editor.

This new behaviour is implemented in _elgg_load_translations(), line 141 of languages.php in engine/lib. In plugins.php instead I noticed that if languages have been cached, languages are not loaded from plugins anymore (line 314). This is what causes problems when trying to access all language data.

Please ask if not clear. I hope that in the future, when I have learned a bit more about this amazing platform, I will be able to actually submit a patch for issues that I find ;-)
@elgg-gitbot
Copy link
Author

cash wrote on 42480630-05-12

Turn off the system cache and everything will be loaded as in Elgg 1.7 through Elgg 1.8.3. In the future we could provide a function to load that info when required or cache it. Thanks for the report.

@elgg-gitbot
Copy link
Author

trac user fmestrone wrote on 42483016-09-06

Thanks. I think the only thing it takes is the caching of language_paths as well, so that when needed the
== _elgg_load_translations ==
method can still go through all paths and load all translations. Something along the lines of

                // PATCH for bug #4620
                elgg_save_system_cache("language_paths", serialize($CONFIG->language_paths));
                // END PATCH

inserted at line 446 of engine/lib/cache.php and

        // PATCH for bug #4620
        if ( $CONFIG->system_cache_enabled ) {
            $CONFIG->language_paths = unserialize(elgg_load_system_cache('language_paths'));
        }
        // END PATCH

inserted at line 248 of engine/lib/languages.php

almost does the job.

@elgg-gitbot
Copy link
Author

cash wrote on 42483026-08-19

If the language paths are cached, you'll want to call reload_all_translations() to get everything loaded.

@elgg-gitbot
Copy link
Author

Title changed from Language Caching in 1.8.6 to Language Caching makes it a little harder to support translation tools by cash on 42515055-01-15

@elgg-gitbot elgg-gitbot reopened this Feb 17, 2013
@cash
Copy link
Contributor

cash commented Jul 6, 2013

My translation rewrite solves this. Assigning to 1.9.

@ghost ghost assigned cash Jul 9, 2013
@cash
Copy link
Contributor

cash commented Sep 27, 2013

Pushing this off to 1.10

@ewinslow ewinslow removed this from the Elgg 1.10.0 milestone Jun 13, 2014
@jdalsem
Copy link
Member

jdalsem commented Oct 23, 2014

The translation editor works pretty well with Elgg 1.9.x, so i am unclear why we should keep this ticket open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cash cash

Labels
engine
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cash @ewinslow @jdalsem @elgg-gitbot