Closed GoogleCodeExporter closed 9 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
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
Original comment by ctrlal...@gmail.com
on 24 Jul 2013 at 1:46
Moved to github: https://github.com/pradosoft/prado/issues
Original comment by ctrlal...@gmail.com
on 1 Oct 2013 at 10:14
Original issue reported on code.google.com by
ra...@bhatia.at
on 16 Mar 2013 at 2:30