silverstripe does not seem to pick up changes in the language yml files. This used to work. As usual I am doing ?flush=all after the files are changed...
In the templates I am using the t- function like <%t General.GoToPortfolio "zum Portfolio" %>
I was editing existing entries, but the template always shows the old 'version' of the entry. If I remove the en.yml file then the translations are really gone. So I am assuming it works at least a little bit...
At the moment I am using silverstripe 3.1.12
The files are saved here e.g.: module/lang/en.yml
Thanks,
Florian
I had this problems some time ago with german umlauts and wrong encoding of the files. So either tell your editor or IDE to encode and write proper utf-8 (best without bom) or htmlencode your umlauts.
finally found it:
deleted the contents of silverstripe-cache folder and it worked.
Related
We have a windows forms legacy asp.net site that uses the AjaxFileUpload control to manage file uploads. One of our issues is that we have different file type uploads but these types are distinguished not by the extension, but by an element right before the extnsion, EG: .gh.zip vs. .gy.zip. It seems that if I add one of these, but not the other, to the AllowedFileTypes, it doesn't allow either. Is it possible to piggyback some additional JS validation code to prevent an invalid file name, or would I need to replace the entire module with something else, and if so, what would be the recommendation for something that's going to be the least time-consuming that will offer a reasonable amount of configuratability?
That control is open source - you can download the source and change it if you wish.
However, why would not just specifying zip as allowed file type work?
If I set a allowed extension of zip?
Then all of these work:
.gh.zip ok
.gy.zip ok
.pdf no
However, my markup is this:
<ajaxToolkit:AjaxFileUpload ID="AjaxFileUpload1" runat="server"
OnClientUploadCompleteAll="MyCompleteAll" ChunkSize="16384"
AllowedFileTypes="zip"
/>
So, above only allows zip files.
if I try to say add a pdf file to above que, then I get this:
So just add allowed extension type = zip
(Edit: do NOT include the "." in this extension)
I not sure why that would not work?
But as noted, you can grab the source - it is open source code now.
However, I suspect perhaps some other issue is going on here?
Or maybe you need "more" complex file extensions parsing?
I mean, you could for the "rare" cases or say some "out liner" cases allow that file up-load, and THEN the post-processing code could reject the file type anyway, right?
However, looking at above, just specify file type = zip, and you should be ok.
I've got an issue with a Wordpress that I'm taking over now.
There is a .mo file containing some translations and a .po file that seems to be the source. The .po file seems have been generated somehow but its structure look a little weird to me.
Here is what can be found inside.
#: /Users/yui/Sites/fondation/wp-content/themes/fondation/taxonomy-programme.php:24
msgid "Exhibitions"
msgstr "Expositions"
#: /Users/yui/Sites/fondation/wp-content/themes/fondation/archive.php:69
#: /Users/yui/Sites/fondation/wp-content/themes/fondation/single.php:43
msgid "[:en]Events[:fr]Evénements[:de]Events[:pl]Events"
msgstr ""
When I try to generate the .mo file msgcat fondation-fr_FR.po | msgfmt -o fondation-fr_FR.mo - the .mo file contains only the first one (with both msgid and msgstr) but not the other one. The website also have an issue with that and display only the translation found in the .mo file.
Any thoughts on how to fix the .po file? Is it an old format?
but its structure look a little weird to me.
Indeed. Looks like being done by somebody who had no idea how gettext works or that manuals are a thing and creatively abused gettext files (case in point: see the multiple translations in the msgid of all places).
The second string is not included in the compiled translations table (i.e. MO) because it has no translation — msgstr is empty.
BTW, everything about how gettext works, including how strings are retrieved and why it makes no sense to include untranslated entries in MO (hint: the string is already in the code!), is very well explained in the GNU gettext manual.
BTW2, that invocation of msgcat is also an entirely pointless busy work — see its man page for what it does (same as cat plus some smarts).
For the records.
The .po file had been generated by an old version of qtranslate plugin for Wordpress which didn't know how to properly handle the gettext functions in its firsts versions.
Nothing could be done to get the .po file to work. I had to create a new one manually.
I've been having problem displaying accented characters (and somtimes apostrophes too) in twig. The site's been recently hosted and I was experiencing none of this on my local server. This problem's been encountered before (there's a question about it here but using raw doesn't work for me). In twig, I have something like this:
{{ entry.textFr|striptags|raw }}
Despite using the raw filter, I can't get those characters to be displayed right (I'm also aware that the raw tag is dangerous but I fully trust the content of the entry entity).
More profoundly, I'm using symfony2 and stfalcon's tinymce bundle, which seems to convert those characters automatically before they are persisted in the db. None of this was the case on my local server.
Does someone have an idea?
Edit
In particular, it seems that 'é', 'è', 'à', 'ê', 'ô', as well as ellipsis and apostrophes are displayed as é, è, à, etc. I've just tried using the replace filter like this |replace({é': 'é', 'è': 'è', 'à': 'à', //ect }) and it seems to work but it's kind of dirty
Edit 2
Nevermind. I just made a twig filter with html_entity_decode. Didn't wanna use that solution but couldn't find anything else.
I had the same problem, and as I see, lots of people are still having it.
After long researches, I solved with Convert Encoding this way:
{{ mytext|striptags|trim|convert_encoding('UTF-8', 'HTML-ENTITIES') }}
("trim" can be omitted for the post purpose, it was just used to have a cleaner string, in my case)
Working with Laravel - October CMS I solved this issue adding a charset metatag in each file, the parent with "head" closure and childrens without.
I hope somebody can save a noob: We have a simple multi language site and want to move it to wordpress. Problem: We had it translated like this: Example Translation and it looks like the theme I want in wordpress handles multilanguage in .po and .mo files.
All the texts remain the same and we clearly can't translate the whole site again. Is there an easy way to convert the text files? What would the most hassle-free method be?
Any help, tips, or recommendation is hugely appreciated.
the .po files have a complete different structure then the file shown
###############
# meta
###############
define("L_TITLE_HOME", "HOME");
define("L_TITLE_REFERENCE", "Referenzen");
define("L_TITLE_SOFTWARE", "Unsere Software");
define("L_TITLE_COMPANY", "Über uns");
define("L_TITLE_PARTNER", "Für Partner");
define("L_TITLE_INVESTOR", "Für Investoren");
the gettext system doesn't recognize this type of files, so the best way i see you gonna have to copy the original .po file on your theme, rename it and then make the input off the translated vars manually.
But the best way in the the other languages its to have them translated directly on the respective .po files to avoid conflicts like this.
I have several SQLITE files all of which have Kind set correctly to Document except for one which is Kind = Unix Executable file. It still loads and runs fine. I'd like to clean this up but can't find a way to change Kind for this file to Document.
Anybody know why Kind would have been set incorrectly in the first place and how to change it to the correct value? I've searched here and on Google.
Is there an extension (possibly hidden) set on the file? I think that 'Documents' are merely files without extensions. I'd try File>Get Info on it (via Finder) and checking to make sure there isn't a hidden extension in the 'Name & Extension'
I had the same issue with my php_error.log file. It was "document" and then I foolishly changed the "kind". That mean that the php log wouldn't work and my MAMP server didn't recognise it.
It's still "text document", but to fix the issue I opened up the file in TextEdit, selected "make rich text" under format, saved the file, closed it down, reopened it in TextEdit, selected "make plain text" under format, saved the file and it worked...