I use Chameleon Page templates as my templating language and I'd like to give my translators a hint. (In this case because the word "you" can be translated quite differently depending on the context.)
I cannot find a technique for it in the documentation.
How do I do that? Is it even possible?
I could abuse i18n:target but I'd rather not.
The resulting piece of the .po file would look like this:
I'd prefer a solution that produces something like this, which I believe to be the standard gettext way of supplying hints to translators.
#. i18n: Translate this very formally.
msgid "you"
msgstr ""
I've found quite an ugly solution which depends on your translators being somewhat alert.
<tal:block i18n:translate="">
<tal:block
i18n:name="This is not a dynamic element, this is a hint for translators: translate this very formally"
>you</tal:block>
</tal:block>
This will end up in the .po file as follows:
msgid ""
"${This is not a dynamic element, this is a hint for translators: translate this very formally}you"
msgstr ""
Related
Do anyone know if it is possible to localise a TWINE game? I’d like to have my interactive stories in all the Scandinavian languages. I also plan to have mp3 spoken narration in each language for non-readers at a later stage. My thought was to maybe have one complete story file per language but it seems like a hard thing to maintain.
Do anyone have a best-way of doing this?
It may be possible to localize your Twine game's default UI strings, depending on your story format. For example, if you're using the SugarCube v2 story format in Twine, then there are some SugarCube localizations here.
However, for your story text it's entirely up to you how you handle displaying that based on the user's choices. Again, assuming you're using SugarCube, you might have the user select the language in the beginning like this:
<<set $lang = "EN">>
''Select your language:'' <<listbox "$lang" autoselect>>
<<option "English" "EN" >>
<<option "русский" "RU">>
<<option "українська" "UK">>
<<option "Türkçe" "TR">>
<</listbox>>
That will give you a dropdown list of language options.
Then, in each of your passages, you would have something like this:
<<switch $lang>>
<<case "RU">>
(Russian version of passage.)
<<case "UK">>
(Ukranian version of passage.)
<<case "TR">>
(Turkish version of passage.)
<<default>>
(English version of passage.)
<</switch>>
You could put any non-language based code outside of that "switch" macro.
If you're using something other than SugarCube for your story format, then you'll likely use something similar to that.
Hope that helps! :-)
Short story: I'm using Markdown to write a novel. Long story is here. In this site I typo-check the text using a Perl module (which I also developed), but I'd like to check MD syntax too. However, most markdown tool seem to be too lenient on errors, letting go stuff like this
This is an *error
This would be [another error](
Besides, there is no "check-only" option that returns false when there's an error, so that it can be used in continuous integration tests. The only one that balks out in this stuff is maruku. Kramdown, pandoc, marked, markdown (for nodejs), all of them let it go without a glitch.
Question is, is there a markdown syntax validator or checker in any language I can use easily in CI? Or should I go with maruku, despite being considered obsolete by his authors?
As pointed out in this answer, "it is impossible to write "invalid" markdown only markdown that wont do what you want it to." Every string is valid markdown.
You could, however define a subset of markdown that excludes markdown like the examples you mentioned in the question, and modify an existing parser to adhere to that subset.
When I work on web application with my colleges. The name of i18n text are given quite freely.
It's like each one has his own rule of naming.
Take an example, we have a text "Create a new item", it is used for a link.
A names the key in resources file like: CreateANewItem, which puts all word together.
B prefers to name it like this: CreateLinkText, which describes it's usage in the application.
C, however, wants to use: CreateItemText, which summarizes it's literal meaning.
When some text is longer or containing format of dynamic content. Naming varies a lot and agreement is hard to be met.
So I wonder whether there's a good naming rule or convention for the i18n text in different cases: short, long, with format, vulnerable to change, etc. Or how do you do this in your project? With this convention, maintenance can be easy and code is more readable.
Thanks a lot.
It's not something that I have seen so far in coding conventions. I guess it matters a lot less than other issues when it comes to coding standards. That said, I don't know what platform you are using, but if it's .NET there is a very short page on naming conventions for resource identifiers here: http://msdn.microsoft.com/en-us/library/vstudio/ms229037%28v=vs.100%29.aspx
Internalization in Play2 can be done with Message.get("home.title") and language files. What about when you internalizate a page full of textual content and not just one specific header or link?
For example doing Messagefile for a long page representing e.g. product info:
_First header_
Some paragraphs of text
...
_Tenth header_
Tenth paragraph and more text*
Messagefile
a)
product.info = "<many paragraphs of text including headers>"
or splitting one page into html elements
b)
product.info.h1 = "<first header>"
product.info.p1 = "<first para>"
product.info.p2 = "<2nd para>"
For me both solutions doesn't sound right. In first having a vast value for a single key seems bad convention and in latter separating a single page into dozens of keys doesn't sound good either.
Big websites often follow the convention www.site.com/en-us/product/1 of having the language in the URL. So the question is, how do i do in this way and is doing in this way a better way at all? I could easily end up not just translating to dozen languages but doing also dozen times layout changes.
I could use global codesnippets using Messagefile for elements that have a little text and doesn't change often e.g. navigation /view/global/header/somenavbar.scala.html but then i end up only having a complex folder structure.
Another way, a best practise, in Play 2 for internalization than messagefile?
Take a look to the Joscha Feth's solution in play_authenticate Java sample.
There are templates for emails in 3 languages for email confirmation, password reseting etc.
Template for each 'type' of email && each language is kept in single file ie:
_password_reset_en.scala.html
_password_reset_de.scala.html
_password_reset_pl.scala.html
_verify_email_en... etc
And for each 'type' there is an 'parent' template, which contains a condition (common Scala's match check the Tags section of template doc) which returns rendered view depending on detected language:
password_reset.scala.html
Finally, yes, at the beginning I also thought that some kind of madness, but believe me, that technique can be useful. There's field for further improvements I think. Maybe it would be better to move the language conditioning to the controller, hm I think that depends on many factors and it will be great if you'll find a time to investigate this topic.
This may be a stupid question, but here goes.
I've seen several projects using some translation library (e.g. gettext) working with plain english placeholders. So for example:
_("Please enter your name");
instead of abstract placeholders (which has always been my instinctive preference)
_("error_please_enter_name");
I have seen various recommendations on SO to work with the former method, but I don't understand why. What I don't get is what do you do if you need to change the english wording? Because if the actual text is used as the key for all existing translations, you would have to edit all the translations, too, and change each key. Or don't you?
Isn't that awfully cumbersome? Why is this the industry standard?
It's definitely not proper normalization to do it this way. Are there massive advantages to this method that I'm not seeing?
Yes, you have to alter the existing translation files, and that is a good thing.
If you change the English wording, the translations probably need to change, too. Even if they don't, you need someone who speaks the other language to check.
You prep a new version, and part of the QA process is checking the translations. If the English wording changed and nobody checked the translation, it'll stick out like a sore thumb and it'll get fixed.
The main language is already existent: you don't need to translate it.
Translators have better context with a real sentence than vague placeholders.
The placeholders are just the keys, it's still possible to change the original language by creating a translation for it. Because when the translation doesn't exists, it uses the placeholder as the translated text.
We've been using abstract placeholders for a while and it was pretty annoying having to write everything twice when creating a new function. When English is the placeholder, you just write the code in English, you have meaningful output from the start and don't have to think about naming placeholders.
So my reason would be less work for the developers.
I like your second approach. When translating texts you always have the problem of homonyms. Like 'open' can mean a state of a window but also the verb to perform the action. In other languages these homonyms may not exist. That's why you should be able to add meaning to your placeholders. Best approach is to put this meaning in your text library. If this is not possible on the platform the framework you use, it might be a good idea to define a 'development language'. This language will add meaning to the text entries like: 'action_open' and 'state_open'. you will off course have to put extra effort i translating this language to plain english (or the language you develop for). I have put this philosophy in some large projects and in the long run this saves some time (and headaches).
The best way in my opinion is keeping meaning separate so if you develop your own translation library or the one you use supports it you can do something like this:
_(i18n("Please enter your name", "error_please_enter_name"));
Where:
i18n(text, meaning)
Interesting question. I assume the main reason is that you don't have to care about translation or localization files during development as the main language is in the code itself.
Well it probably is just that it's easier to read, and so easier to translate. I'm of the opinion that your way is best for scalability, but it does just require that extra bit of effort, which some developers might not consider worth it... and for some projects, it probably isn't.
There's a fallback hierarchy, from most specific locale to the unlocalised version in the source code.
So French in France might have the following fallback route:
fr_FR
fr
Unlocalised. Source code.
As a result, having proper English sentences in the source code ensures that if a particular translation is not provided for in step (1) or (2), you will at least get a proper understandable sentence than random programmer garbage like “error_file_not_found”.
Plus, what do you do if it is a format string: “Sorry but the %s does not exist” ? Worse still: “Written %s entries to %s, total size: %d” ?
Quite old question but one additional reason I haven't seen in the answers yet:
You could end up with more placeholders than necessary, thus more work for translators and possible inconsistent translations. However, good editors like Poedit or Gtranslator can probably help with that.
To stick with your example:
The text "Please enter your name" could appear in a different context in a different template (that the developer is most likely not aware of and shouldn't need to be). E.g. it could be used not as an error but as a prompt like a placeholder of an input field.
If you use
_("Please enter your name");
it would be reusable, the developer can be unaware of the already existing key for an error message and would just use the same text intuitively.
However, if you used
_("error_please_enter_name");
in a previous template, developers wouldn't necessarily be aware of it and would make up a second key (most likely according to a predefined wording scheme to not end up in complete chaos), e.g.
_("prompt_please_enter_name");
which then has to be translated again.
So I think that doesn't scale very well. A pre-agreed wording scheme of suffixes/prefixes e.g. for contexts can never be as precise as the text itself I think (either too verbose or too general, beforehand you don't know and afterwards it's difficult to change) and is more work for the developer that's not worth it IMHO.
Does anybody agree/disagree?