Not sure if i overlooked something, but is there a way to see/test the HTML output of the translations?
How can we make sure that the translated guide keeps track of changes to the english version?
For other translators: I think, an excellent framework should have an excellent documentation . So to assure good quality and consistency of the translations i suggest to create translation guidelines in the yiidoc wiki for each language. I’ll make a start with German…
When I get time, I will add an app to yiidoc to allow viewing the translation in HTML.
I can't think of a good way to synchronize the guide translations. Perhaps each page translation should keep a revision ID of the original page so that in future a new revision is found with the original page, the translation can be synchronized accordingly.
Not sure if we have that much influence on the english version and i guess, you already have such a guide somewhere your brain . But anyway, here at least the vision i put to the german wiki guideline (in german of course):
Quote
Yii is an excellent framework with all but exemplary code. In the same way the documentation should be outstanding by good readability. That's why we try to give some guidance for translation here.
2. How can we make sure that the translated guide keeps track of changes to the english version?
I saved a second local copy of the english source for my translations as of yesterday. I will use them for a future diff comparison if needed. I also write protected the local svn copy of the source in order to easily track changed files (not write protected). There might be better ways…
Yes, please leave the word "info" untranslated. It is used to format the blockquote. Thanks.
OK.
Quote
Is this also true for "Note", "Tip", etc?
My investigation tells yes. These are translated in HTML as '<blockquote class="tip/info/note etc.">', when the word has '>' in the beginning of a sentence.
It indeed is, and I would suggest this modification of MarkdownParser.php:
public function _doBlockQuotes_callback($matches)
{
...
# Do blockquote tips/notes
//$bq = preg_replace_callback('/^(s*<p>s*)([a-z]+):s*/sxi',
$bq = preg_replace_callback('/^(s*<p>s*)([a-z]+)([ ]*)([S]*):s*/sxi',
array($this, 'doBlockquoteTypes'), $bq);
$attr= $this->_blockquoteType ? " class="{$this->_blockquoteType}"" : '';
return "n". $this->hashBlock("<blockquote{$attr}>n$bqn</blockquote>")."nn";
}
public function doBlockquoteTypes($matches)
{
$this->_blockquoteType = strtolower($matches[2]);
//$type_str= ucwords($this->_blockquoteType);
$type_str= ucwords($matches[4]?strtolower($matches[4]):$this->_blockquoteType);
return "<p><strong>$type_str:</strong> ";
}
Should be backward compatible and extended format then becomes:
...
> originaltoken translatedtoken: text block
...
At least this works for my translation and national characters (åäö).
/Tommy
Edit: I guess we could match zero or no more than one literal space character as separator (or some other separator such as '/'). I'm not sure about the regexp syntax for 0…1 cardinality.
Would it be useful to translate into languages like Filipino who mostly use English, I was thinking there is a greater chance of more local popularity if it is in the national language?
When I turn the page to Japanese by clicking, japanese toc.txt is displayed according to the langueage in terms of the helper application of the index.php. On the ohter hand, it is not shown in the guide.
The version you saw on yiiframework.com is 1.0.2, which does not have the Japanese toc yet. We will update it when 1.0.3 comes out.
Sorry for my confusion. Actually, I am looking at *.txt in SVN using a helper application of the document. Though I knew other documents exist only in SVN, but I forgot that the toc.txt exists only in SVN as well.
Regarding translation of messages, about the pair [key|english] => [value|translation]:
I was wondering: wouldn't be more convenient if the key english message was copied into value message already?
I have to copy paste the message myself every time. I guess I can make a simple php to do all copy/paste work, but I am not familiar with regular expressions to make a more advanced script.
Do you feel what I am talking about to be a good idea?
Well, as far as I understand, if your souce language is English and target is English also, you don't need the en_US (or en_*) file, if translation is not found, key is shown. Am I right, Qiang?
I think he/she means to have the the messages duplicated in the right hand side as a starting point for the translation. I use to do this too, but it might just complicating things in other languages, I guess. If implemented, a separate template for translations would be better since we would need a clear indication that the right hand isn't yet translated.
Question to Qiang: When will the final 1.0.3 merge to trunk take place? (EST, GMT/UTC or CEST. )