I have 2 servers which I though were synchronized (dev and live) but the "News System" (extension key "news") makes something different.
In the dev server this line
<f:format.date format="%A">{newsItem.datetime}</f:format.date>
outputs "Freitag", as expected (Thats friday in German)
But in the Live Server, it outputs %AM. Which is even weirder is that l (alone, without %) outputs "Friday" in English.
I've checked all the configurations I've seen and I cant seem to find where the difference between the systems is.
Any idea?
TYPO3 is using DateTime::format (http://de2.php.net/manual/en/datetime.format.php) to format the date. This method is using the same syntax of date() which is not using locales, so all output is english.
The only thing I can not explain is why your dev enviroment accepts %A to render the date. Are there different PHP-Versions? Which TYPO3 Version are you using? Get a look at /typo3/sysext/fluid/Classes/ViewHelpers/Format/DateViewHelper.php, you will get the answer there.
I just solved it! Turns out I had 4.7.7 in my live server, and that doesnt support stftime.
Funny, I never thought that such an important feature would be added in an 4.7.X update...
Related
Running into an issue when using EncodeForHTML for certain characters (Emojis in this case)
The text in this case is:
⌛️a😊b👍c😟 💥🍉🍔 💩 🤦🏼♀️🤦🏼♀️🤦🏼♀️ 😘
Now if I just a straight output
<cfoutput>#txt#</cfoutput>
It displays correctly, no issues, but if I use EncodeForHTML first
<cfoutput>#EncodeForHTML(txt)#</cfoutput>
I get this
⌛️a��b��c�� ������ �� ����♀️����♀️����♀️ ��
I tested it with EncodeForXML & esapiEncode as well to be sure; all are giving me the same result.
I've verified the encoding settings in Lucee are UTF-8, and the meta charset tag is also set to UTF-8. I can't find any documenation re: EncodeForHTML saying if it make any changes to the character encoding, if it requires the character encoding to be something specific, or if it has any known issues with emojis or certain code points.
I appreciate any help or clarification anyone can provide.
Edit: Thank you everyone. Wish I could accept multiple answers.
I was required to sanitize emojis in order ensure that third-party content was cross-compatible with external services. Some of the content contained emojis and was causing export/import problems. I wrote a ColdFusion wrapper for the emoji-java library to identify, sanitize and convert emojis.
https://github.com/JamoCA/cf-emoji-java
For example, the parseToAliases() function "replaces all the emoji's unicodes found in a string by their aliases".
emojijava = new emojijava();
emojijava.parseToAliases('I like 🍕'); // I like :pizza:
To "encode" you could use either the parseToHtmlDecimal() or parseToHtmlHexadecimal() functions prior to using EncodeForHTML().
emojijava = new emojijava();
test = emojijava.parseToHtmlDecimal('I like 🍕'); // I ❤️ 🍕
EncodeForHTML(test);
At the time of this writing, ColdFusion's latest version is 2018 update 9
In turn, it uses ESAPI 2.1.1
Recent release notes don't mention Emoji,
https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation
But they do mention in Pull request 413
"Fixing ESAPI's inability to handle non-BMP codepoints."
This dates from 2017
https://github.com/ESAPI/esapi-java-legacy/pull/413
So based on all this information, I would recommend doing both of the following
Try using ESAPI directly. This is how it was done before ESAPI was added to CF. This issue may or may not still exist in ESAPI
Put in a ticket with Adobe to update this library.
Yes, ESAPI 2.2.0.0 addressed the issue of not correctly encoding non-BMP characters (see https://github.com/ESAPI/esapi-java-legacy/issues/300) as part of PR #413 that James mentioned above.
But I just uploaded release ESAPI 2.2.1.0-RC1 (release candidate 1) to Maven Central early this morning and hope to have an official 2.2.1.0 release out by next weekend, so if you are going to put in a ticket with Adobe for fix this with an updated version of ESAPI, I'd wait another week and then tell them to update to 2.2.1.0.
I've struggling a lot with this problem since last week: I am using R presentation (.Rpres file) for the first time and it started alright, meaning that I could build a slide and visualize the result in the Presentation tab in RStudio. However, for reasons I don't understand, after a few hours of working on my presentations the Presentation tab began to show weird symbols for all the french characters in my presentation. The only way so far I could get the presentation back to showing the right characters was by playing with the "Save with encoding..." and "Reopen with encoding..." options in Rstudio.
The problem is that although this has made the french characters in the presentation look good, it is now the text in the source file (.RPres) that looks all weird (e.g. "température" instead of "température").
Here is some more details on my setup, if this can help:
> sessionInfo()
R version 3.2.3 (2015-12-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=French_Canada.1252 LC_CTYPE=French_Canada.1252 LC_MONETARY=French_Canada.1252
[4] LC_NUMERIC=C LC_TIME=French_Canada.1252
attached base packages:
[1] graphics grDevices datasets stats utils methods base
other attached packages:
[1] readxl_0.1.1 sp_1.2-2 foreign_0.8-66 data.table_1.9.6 dplyr_0.4.3 bit64_0.9-5
[7] bit_1.1-12 RPostgres_0.1 DBI_0.3.1.9008 Rcpp_0.12.3.2
loaded via a namespace (and not attached):
[1] lattice_0.20-33 assertthat_0.1 chron_2.3-47 grid_3.2.3 R6_2.1.2 magrittr_1.5
[7] tools_3.2.3 parallel_3.2.3
I really hope someone will find a solution to this as I like this tool and would like to keep using i in the future. I was thinking of trying the revealjs package as an alternative to fix my problem but I haven't (not sure I won't have the same problem).
Thanks for your help.
This problem might be related to the locale specified for your computer, as explained here: https://superuser.com/questions/655273/r-locale-setting-problems-on-mac-os-x
If the result of system("locale") contains a lot of values "C", then you should try the command
system("defaults write org.R-project.R force.LANG en_US.UTF-8")
After this, you should restart R and use system("locale") to check that the locale has been updated, and hopefully you should now be able to get the correct characters the next time you compile your document.
Note: I know that this strategy has solved a similar problem for users on Linux and OS X, but I don't know if it also works if your OS is Windows.
I would like scrape information for recordings from onlinetvrecorder (otr) in Kodi. Unfortunately the scrapers available can't handle the file format which is like
Django_Unchained_15.07.03_22-45_sf2_165_TVOON_DE.mpg.mp4.avi
Renaming is not an option, since the filename is a key for otr. I know there is a scraper called xbmc-otr, but it never left beta status and seems to be outdated.
Any suggestions, on how to correctly display those files in Kodi?
Has anybody written or started a scraper for otr?
After some research I found a solution to the problem. Put the following in %appdata%\Kodi\userdata\advancedsettings.xml (advancedsettings.xml does not exist in advance, you have to create it)
<advancedsettings>
<video>
<cleanstrings action="prepend">
<regexp>_\d\d\.[0-1]\d\.[0-3]\d_[0-2]\d-[0-5]\d_</regexp>
</cleanstrings>
</video>
</advancedsettings>
The regexp <regexp>_\d\d\.[0-1]\d\.[0-3]\d_[0-2]\d-[0-5]\d_</regexp> matches the timestamp in the otr filename, so that everything right of the match (at the end of the file name) is removed. See the official Kodi documentation for further reference. The remaining file name can be handled by the scrapers shipped with Kodi.
Despite of the relatively coarse regexp I added, all my otr movies were recognized correctly.
The solution is tested with Kodi 15.2 (Isengard), but should work with all versions that support the cleanstrings option.
EDIT:
A similar soltuion works for TV Shows. The only requirement is that the file name contains season and episode information like S01E02 for example.
<tvshowmatching action="prepend">
<regexp>_[Ss]([0-9]+)[Ee]([0-9]+)([^\\/_]*)</regexp>
</tvshowmatching>
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.