I am trying to find a way to change the format of the decimal or fixed point field in PFG to accept comma as decimal point, and a decimal as the comma separator. This is for a Brazilian site so we are trying to match their formatting. I found this post on the Plone-Users mailing list, which led me to believe setting the site language to Portuguese would fix it but the site's language was already set to Portuguese. There wasn't really a resolution found on that page, and I am still having issues.
Plone 4.3.2
PloneFormGen 1.7.14
Any suggestions?
I'm not quite sure, but think PFG formatting is based on Archetypes, and only the changelog for https://pypi.python.org/pypi/Products.Archetypes/1.9.8 has comma as decimal separator. And that's definitely after Plone 4.3.2 was released.
You might try on a development copy if updating (pinning) Archetypes to that newer version helps.
Related
I've encountered a Oracle Form which has a strange behavior. It seems that it looses the spanish character "ñ" when converting it from Oracle 10gR2 to Oracle 11gR1. This only seems to happen in Text Field Prompts. The rest of the elements in the form seem to display the characters properly. Any suggestions as to what might cause this or what to check to fix it? I've already have checked that the fonts installed support this character and that the NLS related settings look ok.
Well, after a whole day trying to determine what the problem was, it seems that the simplest answer was the right one: The original developer for this form seemed to want to assure that the character was displayed properly and he had a bad setup, so he was setting the text using the SET_ITEM_PROPERTY function, and using the CHR function to escape the character. Something like the following:
SET_ITEM_PROPERTY('BLOCK.PASS_FIELD', PROMPT_TEXT, 'Contrase'||CHR(241)||'a: ');
That for the prompts for the fields which were titled "Contraseña: " in their properties.
In the current set up, it works, but on this new environmet, we are using an UTF8 encoding and the code for the letter "ñ" changes completely. Just for the sake of completeness the code in utf8 would be CHR(50097). But I suggest it would be better just to ask your DBA or SYSADMIN to fix the NLS settings so you can just use the prompt or field properties and don't have to get this "creative" and make other dev waste too much time.
It never ocurred to me to check for this, because the properties seemed to be set up correctly, but a simple test of creating a new field with the same properties finally showed me that the problem was specific to the 4 fields which were already created and searching for code-based attribute changes led me to find this was the issue. So I leave this answer here in the hope that someone else saves a few hours of his time and checks for the simple answer first.
I just downloaded brackets after hearing that it will probably be the next big editor. I know it is still in beta, but does anyone know how to display foreign characters in this editor? When I try to display a foreign character, this symbol � is displayed.
Can anyone help?
Brackets currently only supports UTF-8 encoded files.
There's an item in the feature backlog to support other encodings, so you should upvote it if that's an important use case for you.
If you're pretty certain that the file you're working with is UTF-8 encoded (bearing in mind that it's tricky to tell for sure), then it sounds like you've hit a bug. As a Brackets core contributor, I definitely encourage you to file it in our issue tracker — and please include a link to the file in question if at all possible.
When saving a Spanish date string value into an Archetypes DateTimeField, the field ends up with a None value. I've read through the DateTimeField code and there is no locale code there at all. I am sure that this, like most things, has already been done somewhere in Plone, and I would like to know where, please.
If it hasn't yet been done, then I would appreciate any comments you might have about my plan. I have collected some information from Google and SO, and this is what I came up with:
1) I will subclass the Archetypes/Field.py/DateTimeField() in my own source.
2) I will use ##plone_portal_state/language() to get the current language code.
3) Then set locale, using locale.setlocale(local.LC_TIME, LANG_CODE).
4) I will convert the string value to a python datetime object.
5) I will use dt2DT to convert the value to zope DateTime.
6) I will then write the value.
This is a silly plan, but it is what I know, and I would love some clues.
Thank you!
I have similar problem, but what I want is to display local time such as Jan 01, 2012 in French in Spanish locale, however doing research I found out that locale.setlocale is not thread safe on most of the systems, so it's not a good idea to keep setting/unsetting it because it will probably set that particular locale for everyone using the site.
You still can install required locales for the selected languages, in Debian you can do this with:
#aptitude install locales
then
#dpkg-reconfigure locales
Select all the locale languages you need and the system would have them. There should be a way of translating month name formats, but I haven't found it yet.
Sources:
Plone discussion -- http://plone.293351.n2.nabble.com/Plone-strftime-and-locales-question-td6602394.html
Python locale documentation page, scroll down to locale.setlocale -- http://docs.python.org/library/locale.html
EDIT: Also instead of locale.setlocale you might want to use babel package, as it appears to be thread-safe, I'm currently investigating that possibility for my own project.
Stack Overflow discussion -- https://stackoverflow.com/a/225106/86294
Babel on Pypi -- http://pypi.python.org/pypi/Babel
I'm adding additional languages to a Drupal site that I'm building.
Getting the translation of content working is fairly easy using the Internationalisation module.
Yet, simple things such as date strings, i.e. day, month and year aren't translated.
I would expect simple things like this to be some of the first things to be translated.
Am I missing something?
For text to be translated, each module needs to pass display text through a specific function (named 't()') which allows the text to be translatable.
It's likely that some module writers are better at doing this consistently than others.
I found the solution to this in the end.
It came down to knowing what to search for in the translate interface admin section.
I was looking to translate month names into different languages and so search for strings matching 'November'. This always came up with nothing.
It truned out that I need to search for 'month'. This then allowed my to add translations for all of the month names and also other date related translations.
Very frustrating the effort required to find that out!
I was learning flex for a few days now and suddenly noticed that input of unicode / foreign characters on Linux into TextInput, TextArea or RichTextEditor gives you unreadable text composed of several characters (seems like utf-8 is making things bad). On the other hand, output is flawless.
I was trying hard to find anything for the same issue on the internet, but only this old blog entry could be seen. Author produced temporary solution but it is not sufficient.
So if Windows allows unicode and Linux doesn't, what should I do? Maybe the problem is on my machine only? Did anybody come up with the same problem and maybe the solution?
I have Adobe Flash 10.0.32.18 installed on my Sabayon Linux box.
Might have something to do with this bug:
Incorrect unicode input in linux
Which, apparently, will get fixed once FP 10.1 is released.
Just to further update the answer. Flex 4 components support unicode and the unicode characters can be typed into input controls using Google Chrome, Firefox 3.6+ and IE7+ .
For Java MySQL users
database.url=jdbc:mysql://localhost:3306/sampledb?useUnicode=true&characterEncoding=utf-8
To allow utf8 data-write operations.
Database table and columns must be set to utf8_* encoding to make sure the unicode data can be stored in the tables.