Re: [Components] template translation
Hi Sascha,
Sascha Frinken schrieb:
> Is this the expected behaviour? If not I will open a bug report for it.
>
> I am expecting it to return the translation of each word.
as you can see in the template component docs, only literal strings are
allowed within translation tags.
http://ezcomponents.org/docs/api/trunk/Template_EBNF.html#translations
You can use a switch to achieve what you want:
{tr_context "existing"}
{use $words=array( 'hello', 'world' }
{foreach $words as $word}
{switch $word}
{case "hello"}{tr "hello"}{/case}
{case "world"}{tr "world"}{/case}
{/switch}
{/foreach}
Regards,
Andi
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] [ezcTemplate] Cannot compile template
Hi, I can't help to solve the problem but I had this problem sometimes, too. It showed up randomly and I couldn't find out what is causing it. In my case most of the template files were compiled without problems and sometimes files randomly caused the Exception. After hitting F5 several times the template compiled. I never had this problem on Windows, just got it on Linux with both CGI and mod_php. Regards, Andi Thomas, Maxime schrieb: > Yes, the process writes effectively the file in the correct directory. > It's not a classical right issue. > > Hélas! > > > Max > > > > > > > > -Message d'origine- > De : Thomas Koch [mailto:tho...@koch.ro] > Envoyé : vendredi 17 avril 2009 16:47 > À : components@lists.ez.no > Cc : Thomas, Maxime > Objet : Re: [Components] [ezcTemplate] Cannot compile template > > Where do you write the compiled templates? Does the PHP process (Apache/CLI?) > has write permissions for this place? > > Best regards, Thomas > > Am Friday 17 April 2009 16:23:59 schrieb Thomas, Maxime: >> Please help Logica to respect the environment by not printing this email > Please send text only to reduce the used bandwidth. > All Spam-Emails produce as much CO2 as do 3.1 million cars. > > > > > Please help Logica to respect the environment by not printing this email / > Pour contribuer comme Logica au respect de l'environnement, merci de ne pas > imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen > Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a > respeitar o ambiente nao imprimindo este correio electronico. > > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any attachment > and all copies and inform the sender. Thank you. > > -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap: Debug & EventLog Components
Hi, >> Custom HTML output or other more application specific things could be >> done with the ezcLogStackWriter by Thomas Koch if somebody would need >> that (http://issues.ez.no/IssueView.php?Id=14104). Thank you for adding it! >> What do you think about adding method overloading for the different >> severity levels ($log->info(), $log->debug(), ...)? > > Doesn't sound like a bad idea... makes the API easier to use I think. > Care to file an enhancement for this? http://issues.ez.no/IssueView.php?Id=14789 >> With this email I'd like to start a discussion about the improvement of >> the EventLog component especially by getting FirePHP support. What do >> you think? > > I wouldn't mind to have it at all... I think it's much better than > having to render the output at the end of the request. I had no time to look at this again until now. I'll have a closer look at the EventLog - FirePHP integration after finishing my thesis (in July I guess). Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] PersistentObject: Regression or not?
Hi Toby, Tobias Schlitt schrieb: > What would you say? I like the idea of reindexing by id as I missed the possibility to access the objects by id and had to do the reindexing by myself. Regards Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] Roadmap: Debug & EventLog Components
Hi, I recently thought about the Debug & EventLog Components and had a look at the Issue Tracker. There are several issues that attracted my attention. Derick added the issue "Investigate on how to improve the Debug and EventLog components" (http://issues.ez.no/IssueView.php?Id=14090). In my opinion the Debug component should be retired completely in favor of the EventLog component. The loss of the HTML output is imo not a problem as there is a better alternative: FirePHP (http://issues.ez.no/IssueView.php?Id=13614). Custom HTML output or other more application specific things could be done with the ezcLogStackWriter by Thomas Koch if somebody would need that (http://issues.ez.no/IssueView.php?Id=14104). Could this be added to the next version btw.? What do you think about adding method overloading for the different severity levels ($log->info(), $log->debug(), ...)? Open questions: * How do we integrate logging of Exceptions and tables (arrays) into the existing API (maybe only usefull for usage with FirePHP)? * How do we add some timer functionality to EventLog? * Do we need to bundle the FirePHP class for a EventLogFirePhpTiein? In the Pear Package the dependency could be added easily as there is a PEAR channel for FirePHP. With this email I'd like to start a discussion about the improvement of the EventLog component especially by getting FirePHP support. What do you think? Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] possible Template Translation Bug
Hi,
>> What I heretofore propose is that
>> A - newlines always be preserved after the closing brace of a statement!
>> B - if this radical change is not welcome, an option is added, either as part
>> of the context object or separately, that decides on the fate of those pesky
>> newlines
>> C - no special provision is made for TR
>> D - a paragraph about this topic is added to the tutorial
>
> I agree about C and D.., but not with A and B directly. As for A, we
> can't simply switch behavior, and for B. adding an option makes it
> confusing again. We should be trying to limit the amount of options
> because we'd like to avoid the 1.000s of options that ezp has now.
>
> I think instead we should make it a property of the context. Now I think
> more of this, it starts to make more sense. The current XHTML context,
> should keep the current behavior (obviously), but there should be a
> context for email and also one for javascript. In case you want to
> change the behavior or the new line handling, you can create your own
> context.
This issue is still on my list of open problems.
I totally disagree with C. Why would I want to keep the newlines after
all elements? I think the only exception where the newline should be
kept is with {tr} as it is embedded within text of e.g. an email.
If I have to care about all newlines in an email template then sticking
to the current state seems to be easier. Even adding additional newlines
after all {tr}s with subsequent newlines keeps the templates more
readable imo.
Therefore there shouldn't be just a general trim whitespace option but
also a special option for {tr}.
Regards,
Andi
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap for the next release
Hi, today I had some time to look at the language extraction problem again. I almost finished the script today and I hope I can post a final version before I go on vacation on Monday ... > One thing I think might be useful is help for the process of updating > software versions, introducing new strings and removing some others. > It would be handy to have a tool that is "diff" oriented: > > - given a set of templates and a translation file, it adds the missing > translations strings to the translation file and outputs the list of > unused strings That's what my script is doing at the moment. It creates a new translation file or updates an existing one. Any unused strings get the status OBSOLETE and could be processed afterwards. I don't think a list of unused strings is a valuable information if I get it on the console while executing the script. > - given two translation files, it can add the missing strings from a to > b [in "unfinished" mode] and output the list of strings in b which are > not in a While writing the script today I thought about these merging, ... stuff. I think this should be in a separate script within the translation package, as this is generic functionality concerning all translation files. Therefore I won't address this issue in the script I'm contributing for the TranslationTieIn. Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] SOAP component / ezcMail Mime Handling
Hi Derick, > We'd need to split out the MIME handling support into perhaps it's own > component. I don't know how feasible that is -- I've little idea on how > SOAP deals with MIME as well - would you have a link to some summarized > information? I need to have a look at the existing MIME code again and see if SOAP does require all the things there and if it wouldn't be less effort to duplicate some code and optimize it for the special purpose in the SOAP component. My implementation is SOAP with Attachments. There is nothing really nice. I started with this: http://www.w3.org/TR/SOAP-attachments#SOAPMultipart Besides SOAP with Attachments there is also MTOM: http://en.wikipedia.org/wiki/MTOM > Which other encodings would you want? Quoted-printable doesn't really > work so well for 8-bit files. And it's also not safe to put raw 8-bit > data into either e-mail or XML as far as I know. Amazon required 8-bit raw for XML attachments (at least it was the only solution that worked). And it would be maybe also necessary to have binary attachments for other files. > I've a question for you here as well - would this sit on top of PHP's > SOAP extension, or something totally new? I'd prefer it actually if some > of this works went into improving the SOAP extension instead if > necessary and useful. Yes it's on top of PHP's extension. I know it's not the best approach and it should be native functionality within the SOAP extension but I can't help with this as I don't know any C besides 'Hello World'. And it's at least better to have a PHP implementation then nothing. The ultimate solution for PHP would be imo to have this extension in PHP core: http://wso2.org/projects/wsf/php as it already has a lot of features. I would have used it if I had been allowed to install it on the server. Then I coded the userland solution. I would like to share this code as it was really annoying for me to find out that I needed to do this for such a common thing. I'll go on with a possible ezcSoap component if you are interested, otherwise I publish the code somewhere else just as it is. I'll look into the three issues with ezcMail MIME in August and file feature requests and maybe provide some patches. Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap for the next release
Gunnstein Lye schrieb: > The req. doc talks about translatable strings in templates, but such strings > can also be placed in PHP files (there are many in the current kernel). This > must be supported. As the title of the requirements document says I want to build a tool for the TemplateTranslationTiein and therefore for extracting from templates and not for extracting strings from PHP code. This script will be part of the TemplateTranslationTiein to have the right dependencies. What you also want would be another script coming with the Translation component for extracting translation function calls in PHP code. As most of the code after the string extraction should be equal this common code could be added to the normal Translation component: - update existing language files with newly added strings - create a new translation file for a new target language from another file This is also the part that needs to be written to finish the script I've done. > The current ezlupdate scans either the kernel and main templates, or a given > extension. I'd like an option to scan everything at once. As far as I know this is not possible as you would build a script that has dependencies on other components. > We currently have a problem with extensions. If you look at ezodf or ezflow [...] This is all ezPublish specific and I don't really have a clue about that. But I don't think this is exactly a problem of extracting and updating the strings but a problem of a proper translation process and tooling afterwards as it is very application specific. What hinders you to pass it through some postprocessing tool afterwards that solves these problems? Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] SOAP component / ezcMail Mime Handling
Hi, some time ago I needed MIME attachments support (http://www.w3.org/TR/SOAP-attachments) for SOAP to interact with an amazon web service. Sadly the PHP SOAP extension only supports the most basic SOAP features. Luckily it was possible to extend the SoapClient class with MIME support in userspace using CURL and by manipulating the XML in- and output messages to/from the SOAP extension. I refactored my quick and dirty solution and think I could build a nice SOAP component based on my existing implementation. If there is interest from the ezc team and/or other people I would proceed with the effort of building a SOAP component by writing a requirements and design document for further discussion (but don't expect sth. before next week). I have to add that I'm mainly interested in the MIME support and therefore won't address other standards at the moment. But I already thought about a plugin mechanism to be able to support e.g. WS-Security by manipulating the DOM of the SOAP message. More about it in the requirements doc later. For SOAP MIME handling you need MIME de-/encoding. Of course I was lazy and didn't want to implement this on my own. So I ended up using the Mail component's implementation. Before I get to some problems I had with the MIME code in ezcMail I want to raise an important question: How do we solve the problem that we don't rely on other components and don't want to duplicate code either? By not adding a SOAP component with MIME support? ;) Any comments? Generally speaking it was quite easy to (ab)use the MIME handling for my purpose, but I had some troubles with the MIME classes: a) ezcMailMultipart::$noMIMEMessage has some text to inform mail clients without MIME support about this problem. It is not possible to disable this and therefore I also had these messages in my SOAP messages. In my case it didn't cause any problems with the server (connecting to amazon), but it definitely shouldn't be there. Can we add an option to disable this? b) ezcMailVirtualFile (all ezcMailFile classes I think) has a fixed encoding (base64) and it is not possible to change it. Why is the encoding fixed? In other parts of the MIME code one can configure that (e.g. ezcMailText)? Therefore I had to extend the class to get the required 8-bit for my XML attachments. c) When parsing a MIME message the detected files are saved to a temporary file on disk. Why? For the SOAP component this is unnecessary overhead as I want to inject the data into the result XML of the SOAP request afterwards. An option to use ezcMailVirtualFile (instead of ezcMailFile) as target would be cool. Ok, that's it for now. If you finally don't remember what this confusingly written mail is all about: - possible new ezcSoap component - the question: How to deal with MIME de-/encoding? - Some drawbacks when using the ezcMail MIME code for sth. else as it's written for. Any comments appreciated. Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] Roadmap for the next release
Hi, I'm quite busy at the moment but I took the time today to write a quick requirements document for a ezlupdate.php script. Most of the required functionality is already in the script I posted some time ago. Therefore it shouldn't be too much work to add the rest. Are there any design rules for a command line script in ezc? I guess a look at existing scripts should be enough (e.g. the PersistentObjectDatabaseSchemaTiein)? Regards Andi Derick Rethans schrieb: On Tue, 24 Jun 2008, Derick Rethans wrote: On Tue, 24 Jun 2008, Andreas Schamberger wrote: I'm missing the translation string extraction for templates in the Roapmap. I can offer to finish the ezlupdate.php that I started to a complete command line script that also has the ability to create the neccessary TS files for new languages. Ah, sorry - I forgot about this :-/ I'd greatly appreciate it of you could help us with this one. I'll add an issue to the tracker for it though. I added an issue now: http://issues.ez.no/IssueView.php?Id=13236&; Perhaps we can kick start this off by creating a requirements document? regards, Derick eZ Component: TemplateTranslationTiein, Requirements ~~~~~~~~ :Author: Andreas Schamberger :Revision: $Revision$ :Date: $Date$ Introduction Description --- With the tr_context and tr template constructs you can add translatable strings to your application's templates. The TranslationTemplate component provides the glue between the Template component and the Translation component. After the template system knows about the translations, it will use the Translation component's mechanism to fetch translations. Current implementation -- The existing functionality allows only to read different translations from language specific translation files. After designing the templates the usual process is to translate all strings into the desired target languages. At the moment there is no way to extract these language strings from a template and store them in a new translation file for translation. Requirements There should be a new command line script that adds the possibility to: - extract all language strings from templates into a translation file - update existing language files with newly added strings from the templates - create a new translation file for a new target language from another file The script should read all templates in a given directory and extract the strings. It should ignore all dot-dirs (.svn, .cvs, ...) from version control systems. Design goals The script should use the existing functionality of the translation component for manipulating translation files. Therefore it won't be possible to delete strings. Obsolete strings should be marked as OBSOLETE. This should be the case if the filename properties of the strings match.-- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] possible Template Translation Bug
Hi,
I found another template translation issue. With ezcTemplateNoContext
(and also in the HTML context) the newline after a translation block is
stripped. Is this the intended behavior? Would be annoying to add
additional newlines within email templates.
For example:
{tr "The user added the following comment:"}
{$action->comment}
The result is then:
"The user added the following comment:The user's comment"
Expected:
"The user added the following comment:
The user's comment"
Regards,
Andi
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] UserInput
Hi, maybe I shouldn't have used the existing issue for my problem... But it seems to be about the same problem: the input filter extension processes an empty string as valid, but in a required form field this should not be the case. The empty check is not about weather the field is set or not (this is handled by REQUIRED|OPTIONAL), but about weather it has a non empty value or not. Instead of "require_string" it is maybe better to call the filter "non_empty_string"? What I want to solve is: a) REQUIRED field (e.g. name) b) filter_type=string c) if user didn't write anything into the input it should be invalid (the string filter of the filter extension allows empty strings, therefore a check for the empty string is needed afterwards...) Hopefully it's clear now what I want and what most likely the author of the issue wanted, too. Regards Andi Derick Rethans schrieb: > On Fri, 9 May 2008, Derick Rethans wrote: > >> On Wed, 7 May 2008, Andreas Schamberger wrote: >> >>> #011394: UserInput::emptyValue >>> http://issues.ez.no/IssueView.php?Id=11394&activeItem=2 > > Just wondering about this one, why can't you just mark them as OPTIONAL > instead of REQUIRED? > > regards, > Derick > -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] UserInput
Derick Rethans schrieb:
>> I also like to have "require_string" as a filter_type:
>> In my eyes it does not make sense to add callbacks for this but instead
>> only strip the 'require_' part of the filter name and check the result
>> afterwards:
>>
>> $checkEmpty = false;
>> $filterName = $inputElement->filterName;
>> if ( substr( $filterName, 0, 8 ) === 'require_' )
>> {
>> $checkEmpty = true;
>> $filterName = substr( $filterName, 8 );
>> }
>> // filter_input call ...
>> if ( ( $value !== null && $checkEmpty === false ) || ( $value !== null
>> && !empty( $value ) ) )
>> {
>> $this->properties[$elementName] = ezcInputForm::VALID;
>> // ...
>>
>> This way the require can also be used to require other filters that
>> output an empty string and not NULL and it doesn't add too much
>> complexity. The usage of "require_" could of course also be restricted
>> to them to make the usage clearer.
>
> Could you file an issue for this please?
I want this kind of implementation for the mentioned issue:
"#011394: UserInput::emptyValue"
http://issues.ez.no/IssueView.php?Id=11394&activeItem=2
The description of the issue is not very detailed and I guess he meant
the same thing like me (some kind of check for empty string elements in
the parseInput() method). I should have made this clearer in my previous
mail.
I don't think an exception should be thrown in this case but the element
should be marked "invalid". This makes sure my example of an intuitive
usage of the component from my previous mail works.
I added a comment to the existing issue instead of filing a new one.
I hope you find a little time to fix that and don't insist too much on
the "add-feature deadline" for this as it is in my eyes essential for
proper usage of the component.
Regards
Andi
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
[Components] UserInput
Hi,
today I started to convert some of my forms to use UserInput. Generally
this is a great component. But there are two major show stoppers in my
eyes that force a programmer to write a lot of unnecessary duplicate
code. And surprisingly there are already two issues for them:
#012345: ezcInputForm->isValid()
http://issues.ez.no/IssueView.php?Id=12345&activeItem=3
#011394: UserInput::emptyValue
http://issues.ez.no/IssueView.php?Id=11394&activeItem=2
Without these two little features it's really annoying as you have to
check also the case of a valid form with an additional foreach loop.
"if( empty( $form->getInvalidProperties() ) )" works only if you allow
empty strings and is still ugly as the bug reporter already notes in
issue #012345.
I also like to have "require_string" as a filter_type:
In my eyes it does not make sense to add callbacks for this but instead
only strip the 'require_' part of the filter name and check the result
afterwards:
$checkEmpty = false;
$filterName = $inputElement->filterName;
if ( substr( $filterName, 0, 8 ) === 'require_' )
{
$checkEmpty = true;
$filterName = substr( $filterName, 8 );
}
// filter_input call ...
if ( ( $value !== null && $checkEmpty === false ) || ( $value !== null
&& !empty( $value ) ) )
{
$this->properties[$elementName] = ezcInputForm::VALID;
// ...
This way the require can also be used to require other filters that
output an empty string and not NULL and it doesn't add too much
complexity. The usage of "require_" could of course also be restricted
to them to make the usage clearer.
With these two issues fixed the component is more intuitive to use:
if ( $form->isValid() )
{
// submit to db ...
}
else
{
// form is not valid, send data to template of this form ...
$properties = array();
$warnings = array();
foreach ( $definition as $name => $dummy )
{
if ( $form->hasValidData( $name ) )
{
$properties[$name] = $form->$name;
}
else
{
$properties[$name] = htmlspecialchars(
$form->getUnsafeRawData( $name ) );
$warnings[$name] = 'invalid_form';
}
}
}
I know it's already late in the release cycle for the 2008.1 release but
could these two still make it into the next release? The code changes
are really small and also no existing APIs are touched.
Regards
Andi
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] Template Custom Function - Problem with HTML-Entities
Hi,
I just had a quick look at the use case of Peter again and I don't think
it is a good idea to add this feature.
This function doesn't need to be implemented as a custom function but
can be done with an included template.
@see: <http://ezcomponents.org/docs/tutorials/Template#include>
It is more intuitive in my eyes to have it with the templates. The only
"drawback" is a little bit more typing ...
You can try to convince me of the opposite if you come up with another
use case where it is really necessary to have this feature.
Regards,
Andi
Derick Rethans schrieb:
> On Fri, 18 Apr 2008, Peter Lukezic wrote:
>
>> My Problem is, when using this function, I need the raw output of this
>> function and I always get it with full html entities like '<select
>> name="...' - ok I think I could use the function like {raw
>> (formSelect(...))} but I don not want to do this like that. Has anyone an
>> idea how to solve my problem?
>
> I don't think that's currently possible, and honestly - I don't think we
> should allow it. The reason to require raw is not only for escaping
> HTML, as the template language is not only made for HTML - but also for
> other contexts (such as e-mail). Requiring raw means that the designer
> of the template thought about different contexts, as well as the
> possibility that this code might not be HTML-safe. Besides this, I don't
> really know if it is possible to do this (by adding another flag to the
> function definition f.e.) because of the internals of the engine. I
> would like to know what other people think here before continuing to
> investigate this.
>
> regards,
> Derick
--
Andreas Schamberger, B.Sc. Information Systems
Nymphenburger Str. 25 - 80335 München
mobil: +49 160 99715762
msn: [EMAIL PROTECTED] - skype: andreass.net
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] TemplateTranslationTiein
Hi,
I've thought about this problem again:
>> Another thing I would recommend to add to the TemplateTranslationTiein
>> is a developer mode for the TemplateTranslationTieIn. I'd like to see a
>> development property in ezcTemplateTranslationConfiguration that makes
>> the ezcTemplateTranslationProvider catch the Exceptions for missing
>> translations/translation files and just return the string from the
>> template. This solution makes it possible to develop with a template
>> that doesn't have a valid translation file yet.
>
> Hmm, I see your point here; however, I don't quite think that this is an
> elegant solution. I don't always want to catch the exception, and
> rethrow it when the configure option is not set, nor having two bits of
> code here for each case. Could you file a feature request for this
> please?
I agree with you that catching the exception in the TranslationProvider
is not nice. I propose to extend the TranslationManager and Translation
classes to a version that catches all exceptions and uses the given key
from the template. This also makes sure we only have to check once if we
are in dev mode or not.
if ( $dev === true )
{
$manager = new ezcTranslationManagerCatchy( $backend );
}
else
{
$manager = new ezcTranslationManager( $backend );
}
I quickly tried this solution and could provide a patch if you want.
Somebody should also come up with a better name :)
In issue #011865
() there is
already a discussion about the introduction of run modes into the base
component. Could this make it into the next version? It doesn't seem to
be a lot of work and could be used globally for cases like the catchy
translation manager.
Regards,
Andi
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] TemplateTranslationTiein
Hi,
I started yesterday with a ezlupdate.php script. I attached what I came
up with until today. Replace "require_once 'init.php';" with your
ezcComponents Setup.
The script reads all templates in a directory and extracts the language
strings. I used the existing functionality of the translation component
for manipulating translation files. Therefore it's not possible to
delete strings. Maybe there should be a new status "DELETED" that makes
storeContext() delete the string from the file.
I mark obsolete strings but only if the filename properties match.
This is not perfect as the filename is an absolute path at the moment
and not relative to the template dir. I'd recommend to change this.
For normal strings this works fine. But if you use HTML or double
quotes, you run into the following problems:
a) xpath for finding messages in 'ts_backend.php', line 436
The xpath query for finding the messages is not working properly if
there are the same strings in different contexts.
Fix: don't use '//' in the xpath query which forces the search to start
at the root element and not within the given context
$result = $xpath->query( 'message/source[text()="' . htmlspecialchars(
$info->original ) . '"]', $contextNode );
b) the same xpath doesn't work if there is HTML in the string
Within the DOM tree all reserved characters seem to be decoded.
Result: The xpath search for the encoded string fails. Therefore there
shouldn't be a htmlspecialchars() call for building the query.
$result = $xpath->query( 'message/source[text()="' . $info->original .
'"]', $contextNode );
HTML is working then.
c) double quotes in translation strings
This doesn't work: {tr "This is the \"root\" element!"}
First problem: String extractor doesn't strip slashes.
stripslashes() needs to be added to visitTranslationTstNode in
ezcTemplateTranslationStringExtracter.
Second problem: All quotes are decoded in the xpath query call (see b))
and therefore it's impossible to have both quote types in one string.
All xpath queries containing double quotes fail.
The only solution I found is to use concat(). The xpath needs to be
changed again:
$result = $xpath->query( 'message/source[text()=concat("'.str_replace(
'"', '",\'"\',"', $info->original ).'","")]', $contextNode );
The concat() function needs at least two parameters. In order to meet
this requirement there is an empty string at the end of every concat() call.
I hope this is what you were looking for.
Regards,
Andi
Derick Rethans schrieb:
On Wed, 2 Apr 2008, Andreas Schamberger wrote:
I've got a question regarding the new TemplateTranslationTiein:
For ezPublish templates there is the ezlupdate program. What are the
plans for ezcTemplate? Update of ezlupdate or plain PHP solution?
There is some code that extracts the translations from templates
already, but it has not been converted into a full blown script yet. For
the eZ Publish version that will use the new template and translation
components there will most likely be a PHP-only solution as replacement
for ezlupdate.
What's the schedule for this missing part of the TemplateTranslationTiein?
We hope to get it done before the release, but there are some slightly
more importent things to be done first. If you are interested in helping
out a bit, that would be most welcome. I attached a script that shows
how to extract strings from a template.
Another thing I would recommend to add to the TemplateTranslationTiein
is a developer mode for the TemplateTranslationTieIn. I'd like to see a
development property in ezcTemplateTranslationConfiguration that makes
the ezcTemplateTranslationProvider catch the Exceptions for missing
translations/translation files and just return the string from the
template. This solution makes it possible to develop with a template
that doesn't have a valid translation file yet.
Hmm, I see your point here; however, I don't quite think that this is an
elegant solution. I don't always want to catch the exception, and
rethrow it when the configure option is not set, nor having two bits of
code here for each case. Could you file a feature request for this
please?
regards,
setOptions( array ( 'format' => '[LOCALE].xml' ) );
// create ts file if it does not exist yet
createMissingTsFile( $backend->buildTranslationFileName( $locale ) );
$backend->initWriter( $locale );
foreach ( $it as $item )
{
$pathname = realpath( $item->getPathname() );
echo $pathname. "\n";
$contexts = getTranslationsFromTemplate( $item->getPathname() );
foreach ( $contexts AS $contextName => $translations )
{
Re: [Components] TemplateTranslationTiein
Hi, thank you for your quick response. I filed a feature request in the issue tracker. <http://issues.ez.no/IssueView.php?Id=12788&activeItem=1> I ran the code snippet and will try to come up with a ezlupdate.php script and post it here as soon it is finished. Regards, Andi Derick Rethans schrieb: > On Wed, 2 Apr 2008, Andreas Schamberger wrote: > >> I've got a question regarding the new TemplateTranslationTiein: >> For ezPublish templates there is the ezlupdate program. What are the >> plans for ezcTemplate? Update of ezlupdate or plain PHP solution? > > There is some code that extracts the translations from templates > already, but it has not been converted into a full blown script yet. For > the eZ Publish version that will use the new template and translation > components there will most likely be a PHP-only solution as replacement > for ezlupdate. > >> What's the schedule for this missing part of the TemplateTranslationTiein? > > We hope to get it done before the release, but there are some slightly > more importent things to be done first. If you are interested in helping > out a bit, that would be most welcome. I attached a script that shows > how to extract strings from a template. > >> Another thing I would recommend to add to the TemplateTranslationTiein >> is a developer mode for the TemplateTranslationTieIn. I'd like to see a >> development property in ezcTemplateTranslationConfiguration that makes >> the ezcTemplateTranslationProvider catch the Exceptions for missing >> translations/translation files and just return the string from the >> template. This solution makes it possible to develop with a template >> that doesn't have a valid translation file yet. > > Hmm, I see your point here; however, I don't quite think that this is an > elegant solution. I don't always want to catch the exception, and > rethrow it when the configure option is not set, nor having two bits of > code here for each case. Could you file a feature request for this > please? > > regards, > -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
[Components] TemplateTranslationTiein
Hi, I've got a question regarding the new TemplateTranslationTiein: For ezPublish templates there is the ezlupdate program. What are the plans for ezcTemplate? Update of ezlupdate or plain PHP solution? What's the schedule for this missing part of the TemplateTranslationTiein? Another thing I would recommend to add to the TemplateTranslationTiein is a developer mode for the TemplateTranslationTieIn. I'd like to see a development property in ezcTemplateTranslationConfiguration that makes the ezcTemplateTranslationProvider catch the Exceptions for missing translations/translation files and just return the string from the template. This solution makes it possible to develop with a template that doesn't have a valid translation file yet. Regards, Andi -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
