--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
There has been some discussion recently about the community making an
effort to improve the modules database. I'm not sure where things are at
currently with that effort, but I think it would be valuable to think
about how translations could be tied in with that work.
It would be great to submit a module to the database, and it is
immediately available for translations to come in.
So, here's what I'm proposing:1. Zend_Translate to replace parts of the i18n class (and the _t() method).3. Switch the default lang format in core to Gettext PO files.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/wRzWu82dhRkJ.
Zend_Translate should be able to be plugged into that without too much bother, but this is another argument for leaving all the existing APIs as the primary APIs rather than deprecating them in favor over some Zend thing.
It does raise a question, however:- Does the new template system work with TextCollector?
- Does TextCollector have a plug-in API so that text collection for the template system can be part of the template system? I can see need for 3 text collector modules so far: PHP, JavaScript, and Templates.
Hi,
Just like to give my input on translations.
We’ve made translation module which enabled in context editing as well as editing translations in a list view. I haven’t been able to publish it as a proper module since it contains a few kinks such as:
· Copying the cached templates but with rewritten versions of _t calls (with input capabilities to enable in site editing) to a new directory
· Selecting said directory when admin user is performing in site translations editing
· Requiring a _ss_environment.php file to do above mentioned switch
Previously we saved any changes directly into the lang files. This was a horrible mistake since it means that any changes made live would be overwritten on a new deploy, or it would require keeping the live lang files while deploying and putting them back when you’re done.
The approach we’re doing now is to store any changes in the database and then add the ability to import, export to and from the database.
Also we’re hooking into controller onBeforeInit to overwrite the lang values with any changes from the database enabling translations edited live to be shown instantly.
Is there any noticeable performance impact from using yml instead of the php lang files? We’re having performance issues as it is and would like to avoid more of them J
Best Regards
Daniel Lindkvist
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
As I understand it, you could provide an alternative Zend_Translate
back-end that reads a database rather than a YML file, so you should
be able to do this without hacks.
You module sounds cool! The one thing that I would suggest is to only
store *modifications from the default* in your database, so that if
the default strings in the PHP files are updated by developers,
these. You might also wish to store the "default en_US value" that
was provided in the code for each of the modified strings - if the
default value in the code changes, you know that your translation
might be out of date.
> Is there any noticeable performance impact from using yml instead of the php lang files? We're having performance issues as it is and would like to avoid more of them :)
If there is we could always cache as a PHP array. I believe that the
yml config system is also going to do this.