Multilanguage Replies

[GoogleCodeExporter]

Multilanguage Replies

[GoogleCodeExporter]

Bernhard,

Thanks for your feedback and support of this project.  I agree with you, 
language
translation would be a nice addition.  I will leave this in the issue queue for
further consideration.

In the meantime, if you implement at setLanguage method on your local copy, 
feel free
to send it to me.  I will gladly include this in future releases and give you 
credit
in the source code.

Thanks,
Andrew

Original comment by [email protected] on 11 Feb 2010 at 7:28

[GoogleCodeExporter]

I've though about this request off and on for the past few days and decided 
that 
language translation is not an area I want to pursue at this time.  It's an 
added 
complexity that I feel is unnecessary.  Unfortunately, this means that you will 
have to 
run the same search and replace commands each time you download and install a 
new 
release of this project.

Thanks again for your feedback and support of this project,
Anrew

Original comment by [email protected] on 16 Feb 2010 at 5:39

• Changed state: WontFix

[GoogleCodeExporter]

I wanted to mention that the latest version release - 1.0.2 - has two form 
attributes (errorMsgFormat and 
emailErrorMsgFormat) that can be used to format the error message that are 
returned.

Original comment by [email protected] on 27 Mar 2010 at 6:28

[GoogleCodeExporter]

Original comment by [email protected] on 12 Apr 2010 at 5:02

• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

The fields should also be multilanguage: by example the True/False or Yes/No 
fields.
In all there is no much translation required, I have about 10 or 15 items.
I don't see the complexity in this, add a folder "translations" to the project 
with a
subfolder for every ISO language that is supported, by example en, fr, de, ...
That folder should contain a class.form.php file with defines for the correct
constants. In your class you use the constants instead of the hardcoded english 
labels.
Then there should be a parameter for the form where you can set the language. By
example: language => 'en'. By default you hardcode it in english (en), unless 
the
parameter given is checked succesfully for an existng translation file.

I can deliver dutch (nl) translations if you want to proceed with this. 

Original comment by [email protected] on 3 Jun 2010 at 2:59

[GoogleCodeExporter]

Thanks for your suggestion.  Feel free to provide the dutch translations.  If 
you would like, you can integrate your 
constants idea directly into class.form.php.  You can checkout a current 
snapshot of the working copy by running  
the following command...

svn checkout http://php-form-builder-class.googlecode.com/svn/trunk/ 
php-form-builder-class

Original comment by [email protected] on 3 Jun 2010 at 3:15

[GoogleCodeExporter]

Apparantly it is more complicated than that. If I'm not mistaking, the js.php 
and
css.php did not exist in the previous version I'm using and I did not encounter 
this
issue before.

The issue I have now is residing within the js.php file. It initiates a new 
instance
of the class.form.php file so this would mean that the language should be saved 
in
the serialised class session variable

Original comment by [email protected] on 3 Jun 2010 at 3:36

[GoogleCodeExporter]

The js.php/css.php implementation was introduced in the 1.0.4 version release 
to accomodate xhtml strict compliance.  Basically, the js/css 
needed for a specific form is loaded into external files instead of being 
dumped into the body tag alongside the form's html markup.

The serialization/un-serialization of the the class session variable is already 
handled for you near the bottom of the elementsToString() function 
(which is invoked within the render() function).

Please let me know if you have any further questions on the inner workings of 
the project.

Original comment by [email protected] on 3 Jun 2010 at 5:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I would like to use PFBC in portuguese and I'm thinking in use gettext and 
contribute it to the project. Any drawback related to this?

Best regards,
Carlos.

Original comment by [email protected] on 20 Mar 2012 at 12:44

[GoogleCodeExporter]

I agree with this issue, all texts should really be grouped somewhere ...
I'd like to use this class on multilingual websites and it's quite silly to 
have to duplicate ALL source code and manually search for every texts for every 
language ...
Not to mention that it has to be done again if we want to upgrade your script 
...

Original comment by conort on 22 Nov 2012 at 9:37

[GoogleCodeExporter]

I suppose you could wrap the form attributes (errorMsgFormat and 
emailErrorMsgFormat) values within gettext. I have not tried this but there 
should be no harm.

As long as the class keeps the same form attribute names, then your gettext 
values should not have an issue upon upgrading the class.

Original comment by [email protected] on 3 Nov 2014 at 6:13