search

power-media / prado3

Automatically exported from code.google.com/p/prado3
Other
0 stars 0 forks source link

Make Prado::localize() configurable #452

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Hi!

It would be very nice to configure my own localize method/class via the 
application.xml.

Consider these use cases:

1. Automatically add some constant values, e.g. {USEREMAIL}, {MYBRAND}, which 
could be auto-magically filled inside such a class.

2. Automatically protocol the used strings to find obsolete ones.

3. Use some special formatting for $text (e.g. <font color=pink>$text</font>) 
to easily spot strings that haven't been translated yet.

What do you think?

Thanks,
Raoul

Original issue reported on code.google.com by ra...@bhatia.at on 16 Mar 2013 at 2:30

GoogleCodeExporter commented 8 years ago 
The globalization class and the translations source can be already defined in 
the application configuration.
Of course it can be extended if needed, but we tipically try to avoid putting 
to much features in the base classes (to avoid bloat) and prefer to let people 
to be able to subclass and us their classes instead of the base ones.

My thoughts on your points:
 1. Prado::localize already accepts as a second parameter an array of key=>values that will be substituted automatically; i suppose that you would like to be able to add these parameters in the application configuration.
The application configuration is not exactly the best place to put actual data, 
since even if cached it can slow down a lot each application startup. I think 
the easiest way would be to just create a MyClass::localize() that reads the 
parameters array from somewhere (an xml file, a database, ...), caches them and 
internally calls Prado::localize() passing the parameters array.

2. That's a bit difficult to achieve with the actual methods: the strings 
extraction for each page occurs only when that specific page is visited, and 
strings can be dynamic aswell, eg coming from a database. Anyway it's something 
that would need to be implemented on each different MessageSource. Have a look 
at the save() methods in framework/I18N/core/MessageSource_* for some 
inspiration.

3. This already exists, have a look at MessageFormat::setUntranslatedPS(). I 
have to admin it's a bit tricky to use it, you need to execute in your 
application startup:
Translation::init('messages'); // messages is the default name of the 
catalogue, change it if needed
Translation::formatter('messages')->setUntranslatedPS(array('prefix,'suffix'));
Of course exposing this possibility a bit better would be a nice addition.

Let me know what you think, we can work on it

Original comment by ctrlal...@gmail.com on 17 Mar 2013 at 11:32

GoogleCodeExporter commented 8 years ago 
Re-reading #1 it seems to me that the fields that you want to use are not 
exactly related to translation.. you could use a parameter tag: <%$ 
ParameterName %> and define a parameter module configuration file:
<module id="parameter" class="System.Util.TParameterModule" 
ParameterFile="Application.Settings" /> to achieve the result

Original comment by ctrlal...@gmail.com on 30 Apr 2013 at 10:41

GoogleCodeExporter commented 8 years ago

Original comment by ctrlal...@gmail.com on 24 Jul 2013 at 1:46

GoogleCodeExporter commented 8 years ago 
Moved to github: https://github.com/pradosoft/prado/issues

Original comment by ctrlal...@gmail.com on 1 Oct 2013 at 10:14