Our documentation made with Sphinx is in two languages (as explained here). We would like to be able to translate the copyright (at the bottom of the page) as well. However, the copyright is set in the configuration (copyright = "2020, myself and others" in conf.py) file in a unique version.
We would like to have something else for the French version (for example, "2020, moi et les autres"). Aside from modifying all the HTML files by hand, what is the best solution?
Related
I just upgraded to Sublime Text 3.
I'm using my existing Color scheme from Sublime Text 2. But now multi language code highlighting no longer works.
Sublime Text 3
Sublime Text 2
Can someone help me comeup with the custom scope for my tmTheme.
Congratulations on upgrading, it was a good choice. I'm using ST3 Build 3120, the latest development build, so the language definitions may have changed somewhat, but not significantly, if you're using the public beta Build 3114. I also use the Neon Color Scheme (full disclosure: I'm the developer), which has a very large number of specific scopes compared to some other color schemes like Monokai or Solarized which reuse the same colors for a variety of different language features. Finally, since I'm a color scheme designer, I use tools like ScopeHunter and ScopeAlways to determine which scopes and theming elements are active at any point in the text.
So, here's a screencap of your code plus a couple of other test lines using Sublime's HTML syntax:
and here is the same code, moments later, captured using the PHP syntax:
What we can see is that, in the lower left corner, ScopeAlways is indicating that, at the position of the cursor, the base scope of the HTML file is text.html.basic, while the PHP one is embedding.php text.html.basic. So far, so good - this is normal. More importantly, however, we can see the obvious difference in highlighting between HTML and PHP, including the contents of the id attribute as compared to the other attributes, and the coloring (or lack thereof) of the embedded PHP code (yes, I know I'm missing a ; at the end of the isolated PHP code at the bottom - adding one in doesn't change anything).
So, my first suggestion would be, if you're not already using it, is to set the syntax of the file to PHP. You can either select from the menu on the far right side of the bottom bar, or by selecting View → Syntax → and choosing from the options available.
If you're already using the PHP syntax, you should know that since the beginning of this year (more or less), many of Sublime's language description syntax files have been significantly or completely rewritten, PHP and HTML among them. They were in sore need of modernization and speed-up in some cases, and with the advent of the sublime-syntax format (much more powerful than the old, but still supported, tmLanguage format), a better regex engine for .sublime-syntax files, and the hiring by Sublime HQ of Will Bond (of Package Control fame) to do a lot of things that Jon Skinner (Sublime's author) didn't have time or interest in doing, the development process of both Sublime itself as well as the syntax definitions (which were open-sourced at the same time) has increased substantially. That is a really long-winded way of saying that a lot of stuff has changed in a relatively short amount of time, and color schemes that were written with the old versions of the HTML and PHP syntaxes in mind may not be perfect for the new versions. So, you may want to either go through the new syntaxes and update your color scheme, if you're that kind of person, or you can try some other schemes like Neon, which have already been through that process.
Getting back to that weird id highlighting - I'm going to release a new version of Neon fairly soon that fixes that issue, and colors the contents of the id attribute just like class or any other attribute. I'll also try and find out why they did that.
I hope this helps. Good luck!
I'm building a quiz that support 20 languages.
One is Maldivian.
How do I support this. Right now I'm having a bunch of square.
I want to know:
- What font should I use.
- Is there an online translator for English-Maldivian? (google translate do not support this)
Maldivian uses the Thaana script, which is not very widely supported in fonts. There are two basic strategies: specify a font-family rule that lists fonts known to contain Thaana letters, hoping that the user has at least one of them installed, or use a downloadable font with #font-family. The latter sounds more realistic in this case. For it, you would need a font that you can legally use that way.
Free fonts that support Thaana include MPH 2B Damase and TITUS Cyberbit Basic.
For generalities, see my Guide to using special characters in HTML.
I would be very surprised at seeing an automatic translator for a small language like Maldivian, and I would also be surprised at seeing an automatic translator that produces decent results when translating a web site.
i want to know how did facebook do it, did they add two different html+css or its just css only for changing there theme for different language or is there any special html attribute that changes the direction for complete site? following are two example, one english and other is arabic.
also i want to add another related question, which is, do you think they translated using some api like google api or did they hard code the translation (hiring someone to do the translation)?
Example picture 1
Example picture 2
Depending on what technology you're using, this concept is known as string externalizing, string resourcing, string internationalization, localization etc. It is possible to do it all in CSS+Javascript, but that wouldn't be a very efficient way to go about doing things, especially if your site had a lot of strings and a lot of translations.
The HTML is different - just look at the HTML source if you're curious. The source is different because the in the code behind the website's front end, strings like "Login" are stored externally in a collection file that might look something like this:
## LANGUAGE = ENGLISH ##
LOGIN = "Login"
PASSWORD = "Password"
When you switch languages, the code behind the front end remains the same, but the code then uses a different external language file. For example, might be the Spanish file for the same application:
## LANGUAGE = SPANISH ##
LOGIN = "Iniciar sesión"
PASSWORD = "contraseña"
The idea is that in order to support new languages, all that needs to be done is to have the original identifier translated into a new language file. The translator doesn't have to be a programmer to translate the above snippit easily.
The final comment is that Facebook has enough money to pay professional translators to provide them with very good translations in many world languages. A long time ago, they allowed users to submit translations as a starting point. It generally is a bad idea to use a free translation API to translate application strings, because most of the time those APIs will not get the grammar correct. Translation APIs are most effective at getting the "overall meaning" of some words and phrases right, but it can also be terribly inaccurate at getting the most-correct word translation for any one particular idiom.
The layout change facebook did is with css changes, they have two separate css, one for right to left and other is left to right, but if there was another language inside english or same vice verse , then they literally use html direction tag, to direct the message in box with right direction.
Suppose I have some sort of proprietary web framework. Should I include a <meta generator="My framework"> tag in the generated files?
I noticed that StackExchange 0.9 applications do that, and wondered what are the pros/cons of doing it. Does it have any effect, or is it just useful for people looking at the source to see?
I've never seen a tag formatted like that before, with an attribute called generator and the generating software as its value. Usually you'll see it presented as name="generator" and the generating software as its corresponding content, for example:
<meta name="generator" content="WordPress 3.0.1" /> <!-- leave this for stats -->
Previously I was unaware of any standard for this, however it looks like HTML5 has gone ahead and standardized the use of "generator" as a metadata name. It describes it thus:
The value must be a free-form string that identifies one of the software packages used to generate the document. This value must not be used on pages whose markup is not generated by software, e.g. pages whose markup was written by a user in a text editor.
In the past when dynamic web apps weren't that prevalent, certain web site editors, like FrontPage (there, I said it), would automatically insert generator tags when you create new HTML documents or publish sites using them. This was taken to mean "This page was created using FrontPage". I don't think any modern editors or IDEs do this anymore, but I could be wrong. It's definitely commonly used in dynamic web apps today, however.
A benefit (or a con?) is that you can show up in searches done for generator.
Automatically generated (also called "auto-generated"—content) is content that's been generated programmatically. In cases where it's intended to manipulate search rankings and not help users, Google may take actions on such content. Some example cases include, but are not limited to:
Text that makes no sense to the reader but which may contain search keywords.
Text translated by an automated tool without human review or curation before publishing.
Text generated through automated processes, such as Markov chains.
Text generated using automated synonymizing or obfuscation techniques.
Text generated from scraping Atom/RSS feeds or search results.
Stitching or combining content from different web pages without adding sufficient value.
form google...
Internationalizing web apps always seems to be a chore. No matter how much you plan ahead for pluggable languages, there's always issues with encoding, funky phrasing that doesn't fit your templates, and other problems.
I think it would be useful to get the SO community's input for a set of things that programmers should look out for when deciding to internationalize their web apps.
Internationalization is hard, here's a few things I've learned from working with 2 websites that were in over 20 different languages:
Use UTF-8 everywhere. No exceptions. HTML, server-side language (watch out for PHP especially), database, etc.
No text in images unless you want a ton of work. Use CSS to put text over images if necessary.
Separate configuration from localization. That way localizers can translate the text and you can deal with different configurations per locale (features, layout, etc). You don't want localizers to have the ability to mess with your app.
Make sure your layouts can deal with text that is 2-3 times longer than English. And also 50% less than English (Japanese and Chinese are often shorter).
Some languages need larger font sizes (Japanese, Chinese)
Colors are locale-specific also. Red and green don't mean the same thing everywhere!
Add a classname that is the locale name to the body tag of your documents. That way you can specify a specific locale's layout in your CSS file easily.
Watch out for variable substitution. Don't split your strings. Leave them whole like this: "You have X new messages" and replace the 'X' with the #.
Different languages have different pluralization. 0, 1, 2-4, 5-7, 7-infinity. Hard to deal with.
Context is difficult. Sometimes localizers need to know where/how a string is used to make sure it's translated correctly.
Resources:
http://interglacial.com/~sburke/tpj/as_html/tpj13.html
http://www.ryandoherty.net/2008/05/26/quick-tips-for-localizing-web-apps/
http://ed.agadak.net/2007/12/one-potato-two-potato-three-potato-four
In my company all our strings are stored in *.properties files. Our build tools build a "test languange" copy of the properties files, which replace a string like this:
Click here
with something like this:
[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]
Now, when we set the language to "test" in our config files, these properties files are used. (And of course we don't ship the test language files).
This allows us to:
Make sure that Unicode characters are displayed correctly, including Japanese/Chinese/Korean.
Make sure that the layout scales appropriately for languages with longer words (German in particular has longer words on average than English).
Spot any hard-coded strings (as they will be in plain-English).
As for the actual translation, this is done by professional translators, not developers.
As an English person living abroad I have become frustrated by many web application's approach to internationalization and have blogged about my frustrations.
My tips would be:
think about how you show an international version of a page
using geolocation might work for many users, but as my examples show for many it will not
why not use the Accept-Language header for determining which language to serve
if a user accesses a page via a search engine then don't redirect them somewhere else e.g. to a homepage in a different language
it's extremely annoying to change language and have a different page reload - either serve the same page or warn the user that the current content is not available in a different language before redirecting them
English is a very common language, so perhaps default to that
But make sure the change language option is clear on the GUI (I like what Google Maps are doing, as shown in the post)
All I see on the Web is companies getting internalization wrong. Getting it right from a user's perspective is tricky indeed.
I have a couple apps that are "bilingual"
I used resource files in ASP.NET1.1
There is also something called the String Resource Tool
Basically you put all your strings in a .RES file for both languages and then determine what file to read from based on Culture or whether someone clicked a Link for the language
The biggest gotcha is making sure the Translations are done correctly