Category: i18n (Multilingual, l10n, Babelfish)
Show subcategories objects| Name | Type |
|---|---|
| Upgrade 4.1->5.0 - Error : x01 : Fatal error on tra.php | tracker item |
| 'Kyiv,' not 'Kiev' | tracker item |
| 'View Articles' - page name not translated | tracker item |
|
"Change language for this page" in translate this page first step
The page of the first step in translating should be as simple as possible. Changing the language of the existing page has nothing to do with translating the existing page, and is even contradictory, since deciding translation implies admitting the language of the existing page will not change. It can even ruin a translation effort, if chosen by mistake. besides, changing the language of a page should remain exceptional, and be left to editors, not to translators. |
tracker item |
|
"Translation of this page is incomplete." / "translation in progress"
The phrase "translation in progress" might be confusing for users, who expect to see only text to translate in the field of text to translate. Plus, it contains code that users might not understand Plus, it is not part of content, it is a metadata. It should not be in the content field. |
tracker item |
|
#3757 ADD : Language Custom and all language files system holding - Proposal MOD ADD for Trunk 7x
!#3757 ADD : Language Custom and all language files system holding - Proposal MOD ADD for Trunk 7x As I can't access in "edit/delete" mode to #3757, I add this one for complements. The problem of access to whishlist is reported in : #3767 !!Complements : !!!To be able to hold [FIX] in language files without direct corrections The fact to have to commit the full language.php for a language when we have to make a change into an invalid translation has multiple not suitable effects : *you can't follow changes *you can't check and think about *you can't validate The new changes with array fusion make forbidden the fact to alter the (system) language with custom.php or other I enhance my proposal with the [FIX]-*-language.php files with are merged and not fused with after all others. The final aim is to make a merge and automatic rewrite of language.php from the merged array "$lang_$lg" from validated [fix]. !!!To files are naturally sorted (normal - UTF8): # language.php or [SYSTEM]-*-language.php # custom.php or [CUSTOM]-*-language.php # [FIX]-*-language.php the "*" is a part of the name which has meaning (content) and can be sorted. particularly non yet translated parts can be separated from main [SYSTEM] and marked. Progressive and controlled (repartition of job for example) translation can be done. Best regards Trebly (ref:B10126-03) PS : I am particularly sensibles on this because I made each day changes and I think not efficient to commit the full French language each day but a little [FIX] with what+date seems a good solution. |
tracker item |
|
$prefs.language does not work properly?
This is related to the Custom Site Header section of Look & Feel on our Web site. We put a top navigation bar which is expected to be showin in different languages depending on the visitor's language (look at http://www.daav.cn/cms/tiki-list_file_gallery.php ). The code in Custom Site Header is like this: <div style=...> <ul> {if $prefs.language eq "cn"} <li>link1 in Chinese</li> ... <li>linkN in Chinese</li> {elseif $prefs.language eq "fr"} <li>link1 in French</li> ... <li>linkN in French</li> {elseif $prefs.language eq "de"} <li>link1 in German</li> ... <li>linkN in German</li> {else} <li>link1 in English</li> ... <li>linkN in English</li> {/if} </ul> </div> however, it seems the top navigation bar is always shown in Chinese even when I set the default browser language to English only. At that time, our php-based language detector works correctly to identify the user/browser language as English (example: our homepage at http://www.daav.cn/ ) but tikiwiki remains in Chinese unchanged. Is there anything wrong with the code or it's just because my Windows XP is in Chinese? Then how to get around this in Tikiwiki? What language do you get on the linked page that I included above? Thanks for any hints. |
tracker item |
|
Working on Japanese Translations
Japanese translations are incomplete. |
tracker item |
| 12.x: site lang doesn't change to lang B through i18n admin panel if that admin has selected language A as user preference | tracker item |
|
sefurl conflicts with best language
Please see: http://tikiwiki.org/tiki-view_blog_post.php?blogId=2&postId=343 |
tracker item |
|
Humphrey
Contributors |
tracker item |
|
Tanzania missing in country tracker list
Seems like Tanzania keeps falling out of the country list. This was the case some years ago. Might as well add Swahili as a language option if applicable. |
tracker item |
|
Multilingual Meta Keywords and Meta Description (and increase 255 characters limit)
Please increase the limit and make it multilingual |
tracker item |
|
changi67
Contributors |
tracker item |
|
workaround to open ticket #2188
This is a workaround for the bug described below. We just had this same problem occur in Tiki Wiki 6.3. Our Architect looked at the code and said the search wasn't recognizing the pages' language. I turned off the multilingual feature that I just turned on last week (May 31, 2011), and our search function worked normally again. This is a cut and paste of the following open bug I found that describes this problem: Status open Rating (1) Ticket ID 2188 Subject Search function does not work when tiki-searchindex.php is first invoked Submitted by Geoff Brickell Priority 9 high Category Bug: Error Tiki Version 2.x Feature Search Description Using the Search link in the application menu invokes tiki-searchindex.php which does not return any results no matter what you search for. Having had a 'failed' search you are however now at tiki-searchresults.php and all subsequent searches work fine. When you use the Search box module you fill in the form and the form 'action' is to run tiki-searchresults.php - and so this works fine. This was previously logged as id 1696 - but this flagged the problem as a usability problem with the tiki support site rather than a possible coding bug - so have submitted this again. Lastmod by Geoff Brickell Created Monday 01 December, 2008 04:40:25 CST LastModif Monday 01 December, 2008 04:46:34 CST |
tracker item |
|
omstefanov
Contributors |
tracker item |
|
5.0RC1 - wiki Editing option "check orthography" ->em error : table "babl_words_fr" missing
Hello, Remark : The editing current page seems to crash if to many changes by cut are made (my page lost). Object : Change of option "check orthography" lead to system error when you save the page : __SYSTEM ERROR La table 'teawik-ld8-50s-new1.babl_words_fr' n'existe pas __ The query was : select `word` from `babl_words_fr` where `word`=? or `word`=? Valeurs : 1. Table 2. table The built query was likely : select `word` from `babl_words_fr` where `word`='Table' or `word`='table' Stacktrace : * tiki-editpage.php : 0 -> {main}(array ( )) *tiki-editpage.php : 853 -> spellcheckreplace(array ( )) *lib\tikilib.php : 1659 -> spellcheckword(array ( )) * lib\tikilib.php : 1704 -> spellcheck_word(array ( )) * lib\bablotron.php : 44 -> word_exists(array ( )) *lib\bablotron.php : 104 -> query(array ( )) * lib\core\lib\TikiDb\Bridge.php : 29 -> query(array ( )) *lib\core\lib\TikiDb\Pdo.php : 119 -> handleQueryError(array ( )) *lib\core\lib\TikiDb.php : 150 -> handle(array ( )) |
tracker item |
|
5.0RC1 - wiki Editing option "check orthography" ->em error : table "babl_words_fr" missing
Hello, After a cut off of adsl line during 3 weeks because of a sinister, I come back (but the speed remain the slowest 300kb/s). hello, When you set the option check-orthography (french language), when you try to save you get the SYSTEM ERROR : La table 'teawik-ld8-50s-new1.babl_words_fr' n'existe pas __The table '<database_name>.babl_words_fr' don't exist__ The query was : select `word` from `babl_words_fr` where `word`=? or `word`=? Valeurs : 1. Table 2. table The built query was likely : select `word` from `babl_words_fr` where `word`='Table' or `word`='table' Stacktrace : * <site_dir>\tiki-editpage.php : 0 -> {main}(array ( )) * <site_dir>\tiki-editpage.php : 853 -> spellcheckreplace(array ( )) * <site_dir>\lib\tikilib.php : 1659 -> spellcheckword(array ( )) * <site_dir>\lib\tikilib.php : 1704 -> spellcheck_word(array ( )) * <site_dir>\lib\bablotron.php : 44 -> word_exists(array ( )) * <site_dir>\lib\bablotron.php : 104 -> query(array ( )) * <site_dir>\lib\core\lib\TikiDb\Bridge.php : 29 -> query(array ( )) * <site_dir>\lib\core\lib\TikiDb\Pdo.php : 119 -> handleQueryError(array ( )) * <site_dir>\lib\core\lib\TikiDb.php : 150 -> handle(array ( )) |
tracker item |
|
5.x: wiki "watch" emails come with iso-8859-1 to me even if chosen utf-8 everywhere in settings; other email ok
{CODE(wrap=>1)}[10:28] <xavi> since a few versions ago, I can't get wiki watch emails with a correct encoding for accents, etc. [10:28] <xavi> smae behavior in many servers (using Tiki 4.x, 5.x... tried with setting utf-8 and iso-8859-1) [10:29] <xavi> I get most emails all right , email reader (thunderbird, gmail, etc.) can read them properly, but not emails from changes in wiki pages... [10:30] <xavi> I wonder if this can be some problem with the encoding in some tpl , or that the code for sending emails from changes in wiki pages uses some different method than the rest of email sending... and that other method is not handling charset properly... (just hypothesis) [10:31] <xavi> asking here first in case someone who already knows the internals of Tiki has some tips... [10:31] <xavi> to quickly refuse some hypothesis... [10:32] * xavi fears looking at the code for this and getting lost in php code , zend code, and other gibberish which he can't understand easily.... [10:41] <xavi> ok, at least I know some more information about the problem (charset for wiki watch emails) [10:42] <xavi> I double checked in one site, and everywhere is set to use utf-8 as encoding (admin general, admin community, and my own user pref settings), but wiki watch emails come with: "content-type: text/plain; charset=iso-8859-1" [10:43] <xavi> ok, this deserves a bug report... {CODE} |
tracker item |
|
updates to lang/hu/language.php
Bugs & Wish list |
tracker item |
| Action buttons missing in 3 themes (Coalesce, Strasa, Ohia) when translating wiki pages | tracker item |
|
Activating plugins doesn't invalidate cache and thus, plugin help doesn't appear on next page edit
--- Activating plugins doesn't invalidate cache and thus, the plugin help doesn't appear on next page edit. To reproduce: 1- edit a wiki page 2- click on the help button 3- scroll down to plugins 4- click on Activate/deactivate plugins which takes you to tiki-admin.php?page=textarea ~~#FF0000:(wrong tab!)~~ 5- Click on plugins 6- Activate a plugin 7- Notice that on next edit, the new plugin is not available 7a) a bug in my text, edit Help was in French, so maybe the cache of another user was appearing |
tracker item |
|
Add Google Translate support
It's easy: http://translate.google.com/translate_tools?hl=en |
tracker item |
|
add language selection list on Installer page
When I start the installation of Tikiwiki, I wondered why it is only in English. Later I read the documentation and know, I should use http://your_host/tiki/tiki-install.php?lang=XX instead of just enter http://your_host/tiki/ to start the installer. But, why make this trick so difficult to be known? |
tracker item |
|
Adding a topic to articles conflicts with language switching
On this site: http://www.brolin.ca/tiki-view_articles.php Articles are in English & in French. Users can toggle between each language. However, if I add a topic to an article, it no longer works. |
tracker item |
;){kind=link}
;){kind=link}
- Files; Values in Maximum width / height of images for a file gallery can to chain of errors and corrupt image files
- Slideshow; Content is not displayed the same depending on the browser used (content may be truncated)
- Wiki page; Being able to save editing but staying in edit mode will help when creating (long) content
- Accessibility; Adding accessibility tools to Tiki
- Plugin Fancytable content not parsed when using Markdown
;){kind=link}
;){kind=link}
As I told about, during upgrading from 4.2 (I am testing from 4.3) many errors occurs. This threated in a global way in id4377.
Here the problem comes from tra.php this generates a __fatal ERROR__
Reason during first tiki-setup __tra.php__ can be called when $tikilib is not yet set then __the function tra_impl crashes__.
It seems that at this stage of installation (managing session prefs) is it, as if getone() should answer false, nothing particular to do :
I have justed added a first level isset on $tikilib
See the joined patched source with comments.