Tiki 4.x - issues that need a fix

View: New views
5 Messages — Rating Filter:   Alert me  

Tiki 4.x - issues that need a fix

by rom-8 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

I just installed a new Tiki 4.x for translating stuff.

What I have found so far:

- Right after Install, when you should get the __DEFAULT CONTENT__ page I get: "driver not found" (pdo not installed by default, no hint what's the problem, no hint to switch to adodb). The silly thing is that the installation of the database worked. Do we use adodb for installation and then switch to pdo? Can't we have a check for pdo, and if it's not available, stick with adodb?

- left menu entries contain ä etc. and some umlauts in admin pages are not properly handled, either. That worked some time ago; I have no idea yet, why those are double html-encoded, example in admin / general:

Logging and Reporting

  PHP Error reporting level:
  Nur für Admin sichtbar            <---- that ü shouldnt be there in plain but executed
  auch Smarty Hinweise anzeigen
  Mails in Tiki Logs protokollieren
  SQL-Abfragen protkollieren

- crosslinks below admin menus: links are not separated with default style, shouldn't there be some more space between them or a | or something?

  Statistiken & Banner:
  Statistiken Referer-Statistik Suchstatistik      <-- that is 3 links, looks like one

Oliver

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Parent Message unknown Re: Tiki 4.x - issues that need a fix

by rom-8 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

> - left menu entries contain ä etc. and some umlauts in admin pages are not
> properly handled, either. That worked some time ago; I have no idea yet, why those
> are double html-encoded, example in admin / general:

Funny thing: I have a dropdown menu with like 5 entries that I translated. I use ä in language.php, so it should display as ä. But shows as ä ... but not for all entries ... some entries are shown correct.

Oliver

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Tiki 4.x - issues that need a fix

by Jean-Marc Libs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The strange thing is: why would a german translator such as you want
to write ä instead of ä ?
ä is just a way for people who use the wrong kind of keyboards to
write ä in html files. There are no benefits to ä compared to ä
for people who can actually type ä.
Especially now that everything is in utf-8 (but for ä, it was already
possible in iso-latin1).
A lot of pages on the web say that ä can be written ä but that's
because a lot of pages were written initially by american qwerty
keyboard users, it does not mean it's a good idea.

The language.php file should contain normal text encoded in UTF-8, not
html text which is parsed as html. This has advantages for normal
translators (not programmers), because what they type is what will be
displayed. For instance, if they want > or &, they don't need to type
> or &.

Jyhem

On Mon, Nov 9, 2009 at 11:27 AM,  <rom@...> wrote:

> Hello,
>
>> - left menu entries contain ä etc. and some umlauts in admin pages are not
>> properly handled, either. That worked some time ago; I have no idea yet, why those
>> are double html-encoded, example in admin / general:
>
> Funny thing: I have a dropdown menu with like 5 entries that I translated. I use ä in language.php, so it should display as ä. But shows as ä ... but not for all entries ... some entries are shown correct.
>
> Oliver
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Parent Message unknown Re: Tiki 4.x - issues that need a fix

by rom-8 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jean-Marc Libs <jeanmarc.libs@...> wrote ..

> The strange thing is: why would a german translator such as you want
> to write ä instead of ä ?

Cause it's HTML output? We even have stuff like <em> <stong> <b> <br /> <i> and <a href..> in translation files, so all strings must get translated correctly.

No? ,)

Sure the html tags should not really be in the translation files, but they are. We really should clean that up asap. We have to clean up translations a lot anyway:

We have

{tr}some sentence{/tr}
vs
{tr}some sentence:{/tr}
vs
{tr}some sentence{/tr}:
vs
{tr}some sentence {/tr}:

etc. Thats all pretty ugly stuff. Sentences should be in {tr} blocks completely, so translators don't have to look up in tpl files if something is missing a '.' at the end etc.

{tr}some sentence:{/tr} should be the choice. I guess {tr}some sentence{/tr}: isnt any good if you want to translate to a right-to-left language or if you want to change the text completely.

And when changing things in Tiki, people should always adjust all the language files too. With each release I retranslation many many lines I translated already for the last release. Only because someone changed the casing in headlines or rewrite texts and did NOT update all language files.

Oliver

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Tiki 4.x - issues that need a fix

by Jean-Marc Libs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, Nov 9, 2009 at 4:01 PM,  <rom@...> wrote:
> Jean-Marc Libs <jeanmarc.libs@...> wrote ..
>
>> The strange thing is: why would a german translator such as you want
>> to write ä instead of ä ?
>
> Cause it's HTML output? We even have stuff like <em> <stong> <b> <br /> <i> and <a href..> in translation files, so all strings must get translated correctly.
>
> No? ,)

Well, one of my points was: ä is quite correct HTML output. It's also
easier to type and easier to read. You are not lazy enough. :)

The other point was: it does not make much sense to have HTML output
in most places which are translated.

> Sure the html tags should not really be in the translation files, but they are. We really should clean that up asap. We have to clean up translations a lot anyway:
>
> We have
>
> {tr}some sentence{/tr}
> vs
> {tr}some sentence:{/tr}
> vs
> {tr}some sentence{/tr}:
> vs
> {tr}some sentence {/tr}:
>
> etc. Thats all pretty ugly stuff. Sentences should be in {tr} blocks completely, so translators don't have to look up in tpl files if something is missing a '.' at the end etc.
>
> {tr}some sentence:{/tr} should be the choice. I guess {tr}some sentence{/tr}: isnt any good if you want to translate to a right-to-left language or if you want to change the text completely.

Yes. And if "some sentence" is translated, both {tr}some sentence{/tr}
and {tr}some sentence:{/tr} are correctly translated (it's explained
in the top text in language.php).

> And when changing things in Tiki, people should always adjust all the language files too. With each release I retranslation many many lines I translated already for the last release. Only because someone changed the casing in headlines or rewrite texts and did NOT update all language files.

Yes.
How to do it is explained here:
http://dev.tikiwiki.org/mass+spelling+correction
and here:
http://dev.tikiwiki.org/Pending+text+corrections

Sadly, I haven't found time to roll the pending text corrections in
ages, and I'm afraid that when I don't, nobody else does either (why?)

Jyhem

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel