when a page is translated in free mode - or copy mode - i do have problems with
config.sys_language_overlay
set to 0 works: this shows all content elements with language id of the foreign language
set to 1 does not work: this shows only the content elements of the default language (remember: free mode - there is no overlay) The elements with the language id of the foreign language are hidden.
set to "hideNonTranlated" does not work: this shows nothing because there are no Overlay-Records in free mode.
So i should set it to 0 which is mentioned in the manual: "This boils down to “free mode” language handling".
BUT:
My editors mix the mode from page to page and so we got many pages in free mode and many others in translated mode.
config.sys_language_overlay = 0
works well in free mode but shows nothing in connected mode.
config.sys_language_overlay = 1
works well in connected mode but shows only the default language in translation.
config.sys_language_overlay = hideNonTranslated
works only in connected mode and shows nothing in free mode.
I found no possibility to change this configuration depending on the translation mode of the actual page. And the editors cannot change it too.
Any idea how to fix this broken behavior?
Thanks!
There exist many issues concerning translation handling in TYPO3, here is a list of a few of them:
https://forge.typo3.org/issues/19114
https://forge.typo3.org/issues/86595
https://forge.typo3.org/issues/86762
https://forge.typo3.org/issues/87121
https://forge.typo3.org/issues/88137
The best is to add info to existing issues or create new ones. Also testing and commenting on fixes for issues can help, as test-cases often are limited and not satisfying every use-case.
Related
According to the documentation here, it looks like there are 16 COLOR_ATTACHMENTS that we can use in webgl2. However, when I print:
console.log(gl.getParameter(gl.MAX_COLOR_ATTACHMENTS));
It returns 8 in the console.
I've search on the internet to learn whether or not there is an extension allowing us to use 16 COLOR_ATTACHMENTS, but I could not find any. Does anyone know what is the problem here?
Thank you in advance.
The documentation you linked to does not say there are 16 color attachments. It just lists constants for 16. How many you actually get is GPU/driver/browser dependent.
According to the spec section 6.2 page 272, 4 is the minimum required by WebGL2, some devices support more than 4. Checking WebGLStats it looks like the most supported is 8.
Note: According to the creator of WebGLStats the reason that there's a tiny percentage reporting only 1 is because some webpages sharing their stats either by their browser or other reasons are falsely claiming WebGL2 support when they don't actually support it.
In TYPO3 8.7.8 LTS and a clean installation with the setting to create one blank basis page during install and the CKEditor extension disabled when you write something in a text element (I think it is the tt_content.bodytext field) it gets transformed (<p> tags added, line breaks removed etc...) even so there is no WYSIWYG-Editor enabled. So this transformation has to happen in the TYPO3 backend.
I'm trying to disable this now for a while but I failed so far. I tried the approaches from https://docs.typo3.org/typo3cms/CoreApiReference/Rte/Transformations/Tsconfig/Index.html
And here mainly
This configuration in "Page TSconfig" will disable the RTE altogether:
RTE.default.disabled = 1
To be precise my Page TSConfig looks like this and the transformation still happens:
RTE.default.proc.dontRemoveUnknownTags_db = 1
RTE.default.proc.entryHTMLparser_db = 0
RTE.default.proc.exitHTMLparser_db = 0
RTE.default.disabled = 1
RTE.config.tt_content.bodytext.proc.dontRemoveUnknownTags_db = 1
RTE.config.tt_content.bodytext.proc.entryHTMLparser_db = 0
RTE.config.tt_content.bodytext.proc.exitHTMLparser_db = 0
RTE.config.tt_content.bodytext.disabled = 1
So the question is, how can I disable the HTML transformations completely? Do I need to add something in the TypoScript Setup (I tried a bit but no luck) or do I have to do something completely different/in a different stop than the Page TSConfig?
Looking at (and debugging) \TYPO3\CMS\Core\Html\RteHtmlParser and here RTE_transform($value, $specConf = [], $direction = 'rte', $thisConfig = []) which seems to be the responsible function for the transformation of this field, I know that the transformations for my case happen in the mode foreach.
I also know that my RTE.default.disabled = 1 wasn't in the wrong place. It was part of the loaded config, however at least at this point it has no effect at all.
What has an effect is setting RTE.default.proc.overruleMode = none or RTE.default.proc.mode = none. One would do it and any string which is not a registered mode works to disable any transformation.
IMHO: The TYPO3 documentation seems as messy as its code base, maybe RTE.default.disabled = 1 has a use case somewhere and maybe you would find it if you would digg further into the documentation but I fear it may also just be an artefact from some old version which most of this pre- and postprocessing logic seems to be (and from what I've seen here in the last two hours I'm not confident other parts of this framework are 'modern', the mere amount of db queries for simplest backend tasks indicates I could be right). Anyways, my problem is solved and good luck to anyone who also needs to work with this reptile from the past for some reason.
tl;dr: set RTE.default.proc.overruleMode = none in your Page TSConfig
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'm pretty sure about the answer to this, but I'm trying a variety of things to get a very stubborn project to work. One idea was to try to run code through a control without defining it on a form.
So, for example, my original code looked like this:
frmProcess.MyViewer.MaxPageSize = 100
frmProcess.MyViewer.ResetPages
frmProcess.MyViewer.AddPageToView "C:\TestPage1.txt"
I've changed it to:
Dim objViewer As MyViewer
objViewer.MaxPageSize = 100
objViewer.ResetPages
objViewer.AddPageToView "C:\TestPage1.txt"
I get an error window with "Run-time error '91': Object variable or With block variable not set".
But there doesn't seem to be a way to 'set' this control. Is this just impossible, or is there another way to do it that doesn't require a form?
EDIT: I ended up abandoning this entire path of activity, as an alternate solution was found that got around the problem I was having with this form freezing. I don't want to delete this question in case someone else comes along and can benefit from the answers, which are potentially useful.
Try this on a form.
Dim objViewer As MyViewer
Set objViewer = Controls.Add("MyViewer", "MyViewer1")
objViewer.MaxPageSize = 100
objViewer.ResetPages
objViewer.AddPageToView "C:\TestPage1.txt"
I've had similar situations in the past. If all else fails and you have to use a form you can do something crude like
1) Set the .Left property of the control to a negative number (like -10000) so the control doesn't appear on the form, the user can not see it
2) Make the entire form not visible..
ActiveX controls normally expect a number of services from their containers, for example persistence. They are also "packaged and marked" in ways that set the kinds of instantiation they support.
See Introduction to ActiveX Controls.
While it is perfectly possible for a control to be created in such a way as to make many of the available services optional, most controls are created from template code that requires a number of them. And most controls that are "visible at runtime" are going to require container services.
However that doesn't mean a control can't be designed to support containerless instantiation. A well known example of such a control is Microsoft Script Control 1.0 (MSScriptControl.ScriptControl) which can be used either way.
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.