I crete new Websharper Sitlet project and declare string within main module like this
Next, I set a breakpoint, start debugging and found that the string does not contain what I wrote in it.
But how could it be?
And all cyrilic outup, which was created by the project by default, looks like this
Upd
Here is full solution with correct strings: https://yadi.sk/d/z-wOkQGQf7QTS
And here is the same with bad output: https://yadi.sk/d/Vy2hmOudf7QaT
I can not realise what is the difference.
Just open and save your files, containing Cyrillic characters: Client.fs, Main.fs ... to Unicode, rebuild the solution and it will show Cyrillic on the application web page.
Related
I have a solution on my Visual Studio and my program's language is Brazillian Portuguese.
Everytime I compile it and execute and it simply doesn't show the characters I wrote.
Example:
int main (void) {
printf("áéíóúàèìòù");
return 0;
}
It simply shows something really strange.
Although, I had tested another time taking the output to a file and it showed the right output, so I think the problem might be in the cmd.
Then, I searched what might be causing the problem and the results were hanging basically on the code page cmd used.
I finally used chcp 1252, but it seems it doens't work with me, so here I am. Does anyone know what code page should I use or what I can do to the source file to it show the right output? Thanks in advance.
I'm assuming C++.
The reason is that the file is saved with UTF-8 encoding, and the string literals are treated as a sequence of bytes.
So if you have "é" in your source code, it's treated as "\c9\a9" and it gets displayed in CP-437 (default Western encoding for Windows Command Prompt) as ├⌐
Solution: either:
save your source files in some 8-bit encoding (for example CP-1252), change the default encoding in VS, and set the terminal to use the same encoding,
or change your terminal to something that support UTF-8, like Cygwin.
This is more of a curiosity than actual problem as there is an easy and propably more preferable workaround. When using Codeigniters form validation and when displaying error message the CI user guide gives two ways to set one's own validation messages: through set_message-method and editing the language file which is located in the system folder.
However when editing the language file to contain error messages in my native language (which contains special character liks 'Ä' and 'Ö') the special characters are replaced with a black diamond. When using the set_message-method from form_validation it works without a problem and the characters are encoded with UTF-8 properly.
I am wondering where lies the problem when using the file instead of the method and how to solve it?
It sounds like the file is not saved by your editor as UTF-8. Make sure that it is.
This is so stupid that I cannot find it anywhere!
Until now I used texblock with few words of text, so I just declared it as a property in text="my_short_text". Now I have several lines of text that I find really weird to put in the xaml.. I've tried to create a new text.txt resource file and tried to bind to the texblock with Path or Source but it didn't work! Where I have to keep my resourcese?
I know this is a noob question but I'm pretty new with WP7 and C#!
The use of an application resource file is where you'd want to store strings, ints, etc...
For WP7, there is an article on MSDN: How to: Build a Localized Application for Windows Phone. Scroll down to the section titled Replacing hard-coded strings with strings in a resource file.
There are examples of using resources all through the MSDN article; even though it's for localization, you can use the same concepts.
I was translating the website and all was working fine but when I put the files in the online server (linux), the translation worked but the accented letters in spanish appear like this �
somebody knows how I can fix it?
If you are using PHP, you probably need to add the bind_textdomain_codeset function to tell the system that your mo file is returning UTF-8 (or whatever you have specified in the PO file). So something like this should of the trick:
$language = 'de_DE';
bindtextdomain($language, APP_ROOT.'locale'); // Define domain
textdomain($language); // Choose domain, translation is looking for in locale/de_DE/LC_MESSAGES/de_DE.mo now
bind_textdomain_codeset($language, 'UTF-8'); // Tell the system out MO files will return UTF8
Appeared like � where? If it's in the web page, you need to make sure the translation is in the same character set as the rest of the HTML and that that character set is properly noted on top.
It seems me to have the same problem. Can't resolve the � symbols.
I have the charset correctly setted in the top of my html (utf-8), and the .po file is also in utf-8. I tried the bind_textdomain_codeset command but didn't work.
Server is linux.
[ RESOLVED ]
Adding this line:
bind_textdomain_codeset("default", "utf-8");
note default instead of language domain. Wonder why..
I am currently developing some functionality that implements some complex calculations. The calculations themselves are explained and defined in Word documents.
What I would like to do is create a hyperlink in each code file that references the assocciated Word document - just as you can in Word itself. Ideally this link would be placed in or near the XML comments for each class.
The files reside on a network share and there are no permissions to worry about.
So far I have the following but it always comes up with a file not found error.
file:///\\165.195.209.3\engdisk1\My Tool\Calculations\111-07 MyToolCalcOne.docx
I've worked out the problem is due to the spaces in the folder and filenames.
My Tool
111-07 MyToolCalcOne.docx
I tried replacing the spaces with %20, thus:
file:///\\165.195.209.3\engdisk1\My%20Tool\Calculations\111-07%20MyToolCalcOne.docx
but with no success.
So the question is; what can I use in place of the spaces?
Or, is there a better way?
One way that works beautifully is to write your own URL handler. It's absolutely trivial to do, but so very powerful and useful.
A registry key can be set to make the OS execute a program of your choice when the registered URL is launched, with the URL text being passed in as a command-line argument. It just takes a few trivial lines of code to will parse the URL in any way you see fit in order to locate and launch the documentation.
The advantages of this:
You can use a much more compact and readable form, e.g. mydocs://MyToolCalcOne.docx
A simplified format means no trouble trying to encode tricky file paths
Your program can search anywhere you like for the file, making the document storage totally portable and relocatable (e.g. you could move your docs into source control or onto a website and just tweak your URL handler to locate the files)
Your URL is unique, so you can differentiate files, web URLs, and documentation URLs
You can register many URLs, so can use different ones for specs, designs, API documentation, etc.
You have complete control over how the document is presented (does it launch Word, an Internet Explorer, or a custom viewer to display the docs, for example?)
I would advise against using spaces in filenames and URLs - spaces have never worked properly under Windows, and always cause problems (or require ugliness like %20) sooner or later. The easiest and cleanest solution is simply to remove the spaces or replace them with something like underscores, dashes or periods.