Finjon Kiang <kiange@...> escribi=C3=B3:=20
>It's an old problem and I have no idea if it also appeared in other
>languages. Base on the information in site-mgr =3D> Translation status,
>I could find:
>
>API (common) =20
>98.3%
> 894 / 909
>Admin (admin) =20
>98.2%
> 606 / 617
>
>But in developer tool, I couldn't find the phrases which I havn't
>translated. Even if I try to search new phrases. I couldn't find
>another language pack had completed (100%) the translation, so I think
>I'm not the only one. :)
I didn't look carefully, but that shouldn't happen at the test =
installation,
that tries to fix that and other problems with the current philosophy of =
how
the count is being done. I'd say I didn't receive any feedback about it =
when
I mass-mailed about it.
Regards.

Moritoshi Oshiro <m-ooshiro@...> escribi=C3=B3:=20
>Hi
>
>At Fri, 30 Jun 2006 10:07:22 +0200,
>Oscar Manuel =3D?UTF-8?Q?G=3DC3=3DB3mez=3D20Senovilla?=3D wrote:
>>=20
>> Moritoshi Oshiro (m-ooshiro@...) escribi=C3=B3:
>>=20
>>=20
>> With this in mind, one has to ask: is really EUC-JP the right charset =
to
>use
>> for japanese? This decision corresponds to the japanese
>translators/users. At
>> this time, you've both seem to have found that "utf-8 works better than
>> euc-jp", and if this is true, maybe a change should be done. I don't =
mean
>that
>> EUC-JP is a wrong charset, but trying to cover all possibilities, maybe
>you
>> have to think about switching to utf-8.
>>=20
>
>You must specify one encoding when creating db in postgresql. So, if
>you need multi-lang, the solution is to use unicode. The first step is
>to convert your data to utf8, then put it in your db, according to my
>cool, technically reliable co-worker.
>
>So, since egw did not convert euc-jp to utf8 during a fresh
>installation, I changed ALL *_ja.lang files to utf8 first.=20
>
>Sorry if I made confusions because of the info based on my poor
>memory. I would really like to be accurate so let me reproduce later.
The accurate question is: what charset do people in Japan use when using a
db? If they all (mostly?) use utf-8, then switch can be a safe bet, but if
most (or many) people use EUC-JP, then there is a problem (unless the same
installation can deal with two different charsets).
>> > BTW if you are also translating the files, please let me know. I am
>> > translating, and I do not like to work on something you are; I
>> > think it is a waste of time.
>>=20
>>=20
>> This is one of the purposes of this list. I expect news about if there
>are
>> more japanese translators.
>
>Yes, it would be really nice to know. I would like to join in an egw
>user group in Japan if there is one. If there is not already, why not
>make one so that we can work on translation, together?
>=20
>=20
> Do you have any info? > Oscar
I usually have the info, but unless I forget and/or find no initial =
activity
that helps me to remind, the info is updated in
http://www.egroupware.org/translations. Theorically all the existing info =
is
there, but you can find that _officially_ there are no current japanese
translators (which is not untrue). This takes to my mind that there have
been some mails to this list from unsuscribed email accounts (I guess it =
was
you, but I might be wrong), and containing attachments. I rejected them
because of these two things, and the text contained (I think) an
explanation.
Regardless it's you or not, let this make clear that if somebody has any
problem and/or want to contribute, mail me privately, but not mail the =
work
to the list.
Regards.

It's an old problem and I have no idea if it also appeared in other
languages. Base on the information in site-mgr => Translation status,
I could find:
API (common)
98.3%
894 / 909
Admin (admin)
98.2%
606 / 617
But in developer tool, I couldn't find the phrases which I havn't
translated. Even if I try to search new phrases. I couldn't find
another language pack had completed (100%) the translation, so I think
I'm not the only one. :)
--
Finjon Kiang

Hi
At Fri, 30 Jun 2006 10:07:22 +0200,
Oscar Manuel =3D?UTF-8?Q?G=3DC3=3DB3mez=3D20Senovilla?=3D wrote:
>=20
> Moritoshi Oshiro (m-ooshiro@...) escribi=F3:
> >
> > Hi
> >
> > > Just a question to the Japanese translators....
> > >
> > > I am trying to use Japanese for my install, but all the translations
> > > are garbled... (strange characters).
> > >
> > > My Database is MySQL 5 (latest as of this writing) using UTF8
> > > (utf8-unicode collation)
> > >
> > > I'm assuming the translations were done in another charset?
> > >
> > > If so, can someone provide me with a flat text file of the
> > > translations so I can put them into the UTF8 database?
> >
> > I had the same problem with egw 1.2, postgresql. The phpgw_ja.lang
> > files are written in EUC-JP which probably is the root cause of the
> > garbled(mojibake) chars.
> >
> > To display chars in UTF-8 correctly, you have to convert the files
> > from EUC-JP to UTF8 if it is a fresh installation.
> >
> > I do not know about how to change a charset if it was upgrading.
>=20
>=20
> I'm not a postgresql user/expert, but the theory for the charset conversi=
on
> for egw lang files is that the egw setup process "tweaks" the tables so t=
hat
> they use by default the specified charset. I don't know if at setup time =
this
> operation failed on the postgresql side or on egw side, so it would be go=
od to
> know. Also, it would be good to know if postgresql is capable of managing
> multiple charsets.
>=20
> With this in mind, one has to ask: is really EUC-JP the right charset to =
use
> for japanese? This decision corresponds to the japanese translators/users=
. At
> this time, you've both seem to have found that "utf-8 works better than
> euc-jp", and if this is true, maybe a change should be done. I don't mean=
that
> EUC-JP is a wrong charset, but trying to cover all possibilities, maybe y=
ou
> have to think about switching to utf-8.
>=20
You must specify one encoding when creating db in postgresql. So, if
you need multi-lang, the solution is to use unicode. The first step is
to convert your data to utf8, then put it in your db, according to my
cool, technically reliable co-worker.
So, since egw did not convert euc-jp to utf8 during a fresh
installation, I changed ALL *_ja.lang files to utf8 first.=20
Sorry if I made confusions because of the info based on my poor
memory. I would really like to be accurate so let me reproduce later.
=20
=20
>=20
> > BTW if you are also translating the files, please let me know. I am
> > translating, and I do not like to work on something you are; I
> > think it is a waste of time.
>=20
>=20
> This is one of the purposes of this list. I expect news about if there are
> more japanese translators.
Yes, it would be really nice to know. I would like to join in an egw
user group in Japan if there is one. If there is not already, why not
make one so that we can work on translation, together?
=20
=20
Do you have any info? > Oscar
Regards,=20
Moritoshi Oshiro

Moritoshi Oshiro (m-ooshiro@...) escribi=C3=B3:
>
> Hi
>
> > Just a question to the Japanese translators....
> >
> > I am trying to use Japanese for my install, but all the translations
> > are garbled... (strange characters).
> >
> > My Database is MySQL 5 (latest as of this writing) using UTF8
> > (utf8-unicode collation)
> >
> > I'm assuming the translations were done in another charset?
> >
> > If so, can someone provide me with a flat text file of the
> > translations so I can put them into the UTF8 database?
>
> I had the same problem with egw 1.2, postgresql. The phpgw_ja.lang
> files are written in EUC-JP which probably is the root cause of the
> garbled(mojibake) chars.
>
> To display chars in UTF-8 correctly, you have to convert the files
> from EUC-JP to UTF8 if it is a fresh installation.
>
> I do not know about how to change a charset if it was upgrading.
I'm not a postgresql user/expert, but the theory for the charset conversi=
on
for egw lang files is that the egw setup process "tweaks" the tables so t=
hat
they use by default the specified charset. I don't know if at setup time =
this
operation failed on the postgresql side or on egw side, so it would be go=
od to
know. Also, it would be good to know if postgresql is capable of managing
multiple charsets.
With this in mind, one has to ask: is really EUC-JP the right charset to =
use
for japanese? This decision corresponds to the japanese translators/users=
. At
this time, you've both seem to have found that "utf-8 works better than
euc-jp", and if this is true, maybe a change should be done. I don't mean=
that
EUC-JP is a wrong charset, but trying to cover all possibilities, maybe y=
ou
have to think about switching to utf-8.
> On many Linux systems(I use fedora core 5), you can use "iconv" to do
> so:
>
> example:
>
> # iconv -f euc-jp -t utf8 phpgw_ja.lang > phpgw_ja.lang.utf
> # mv phpgw_ja.lang phpgw_ja.lang.bak
> # mv phpgw_ja.lang.utf phpgw_ja.lang
>
> You have to convert ALL *_ja.lang files to UTF8.
>
> I hope above info helps.
I didn't read this before. Putting this and the next message together, th=
en it
makes sense and the info in the other mail becomes right. I didn't test i=
t,
but if the above converts the files, then it's the proper solution for ha=
ving
the files in utf-8 (together with setting the "charset" entity in
phpgwapi/setup/phpgw_ja.lang). The setup process isn't stored in the db, =
so
from a point of view to just make it work, it can remain in its current
status, but the desirable situation is to use the same charset in every f=
ile
for a language.
> BTW if you are also translating the files, please let me know. I am
> translating, and I do not like to work on something you are; I
> think it is a waste of time.
This is one of the purposes of this list. I expect news about if there ar=
e
more japanese translators.
Regards.

Moritoshi Oshiro (m-ooshiro@...) escribi=C3=B3:
>
> Hi
>
> FYI
>
> phpgwapi/setup/phpgw_ja.lang
>
> you might also have to change the charset euc-jp written in the above
> file to utf8.
That's wrong info. The charset to use is specified in the "charset" strin=
g in
that file (for the setup process, it's in setup/lang/phpgw_ja.lang, the
"charset" string, too). Changing the charset would only work if you start=
from
scratch, and you set there the charset the lang files for that specific
language. As a workaround, you could (if you find the way on your own) co=
nvert
all your lang files to that charset, and then, reinstall the language fro=
m
/setup/languages.php and crossing your fingers. :)
Regards.

Hi
> Just a question to the Japanese translators....
>
> I am trying to use Japanese for my install, but all the translations
> are garbled... (strange characters).
>
> My Database is MySQL 5 (latest as of this writing) using UTF8
> (utf8-unicode collation)
>
> I'm assuming the translations were done in another charset?
>
> If so, can someone provide me with a flat text file of the
> translations so I can put them into the UTF8 database?
I had the same problem with egw 1.2, postgresql. The phpgw_ja.lang
files are written in EUC-JP which probably is the root cause of the
garbled(mojibake) chars.
To display chars in UTF-8 correctly, you have to convert the files
from EUC-JP to UTF8 if it is a fresh installation.
I do not know about how to change a charset if it was upgrading.
On many Linux systems(I use fedora core 5), you can use "iconv" to do
so:
example:
# iconv -f euc-jp -t utf8 phpgw_ja.lang > phpgw_ja.lang.utf
# mv phpgw_ja.lang phpgw_ja.lang.bak
# mv phpgw_ja.lang.utf phpgw_ja.lang
You have to convert ALL *_ja.lang files to UTF8.
I hope above info helps.
BTW if you are also translating the files, please let me know. I am
translating, and I do not like to work on something you are; I
think it is a waste of time.
Best regards,
Moritoshi Oshiro

Just a question to the Japanese translators....
I am trying to use Japanese for my install, but all the translations
are garbled... (strange characters).
My Database is MySQL 5 (latest as of this writing) using UTF8
(utf8-unicode collation)
I'm assuming the translations were done in another charset?
If so, can someone provide me with a flat text file of the
translations so I can put them into the UTF8 database?

If I really get into close relation with this application, I seriously
think about joining the Turkish Translation team. But now I am a new
user, I can't promise anything. I now also have close relations with
a Turkish Open Source Accounting Application: Turquaz.
I don't know exactly if I can reserve time for that. But in the future
maybe.
On the other hand, I couldn't find any information about how to enable
Turkish language in this application. I have made a successful
installation today. While installation you determine which language
to use. And I am not sure if this adjustment can be changed in the
future.
How can I add Turkish translation files to this installed application
now? My version is: 1.2.102

Hi,
iso-8859-15 is the problem, the wiki code recognices iso-8859-1 and allows
it's special chars to be used in names.=20
You can modify wiki/inc/class.bowiki.inc.php line 22 to check against
iso-8859-1. I never understood why the finnish translation choose to use
that instead of iso-8859-1.=20
Sure I know iso-8859-15 also includes the Euro symbol, but that works in =
eGW
if you use iso-8859-1 too. It has only drawbacks to use -15, as in some
areas we have some special handling for iso-8859-1, which are not used for
finnish at the moment. I think we should change that.
Ralf
TheAslak <kimmo.liimatainen@...> wrote:=20
>The Charset is:
>
>"Current system-charset is 'iso-8859-15'.* To change the charset:
>back up your database, deinstall all applications and re-install the
>backup with "convert backup to charset selected"
>checked.*"
>
>
>
>
>_______________________________________________
>eGroupWare-users mailing list
>eGroupWare-users@...
>https://lists.sourceforge.net/lists/listinfo/egroupware-users
>
>
>
--=20
eGroupWare Training & Support =3D=3D> http://www.egroupware-support.de
1.2 Release Offer: 250Euro for a Standard Update or Installation
including 1h Telefonsupport und ein gedrucktes deutsches Handbuch
Ralf Becker
Outdoor Unlimited Training GmbH
Leibnizstr. 17
67663 Kaiserslautern

> > My apology for not being able to point to the appropriate lines in a
> > source file. If you could tell me exactly where those are in the
> > source code, it would be very much appreciated. I really wanna learn
> > egw and php.
>
>
> I think there's no real need to dive into the php code, but lang() calls, as I
> explained in my reply yesterday. Maybe if a "Japanese exclusive" date format
> existed, then show it like that in the GUI (with the rest of d/m/y, etc
> formats), but that would lead to "hardcode" the format, which is not
> desirable.
>
> Please study the lang calls examples I gave yesterday, in whose case I could
> even fix that myself.
>
Thanks for your advice.
>
> > Also, in Calender where you input a new plan in a small browser window:
> >
> > Owner [userid] Lastname FirstName Updated by
> > ^^^^^^^^^^two tokens.
> >
> > They must be in one token for me to set a translated string in Japanese.
>
>
> At this time, and surely due to variable font size, I can't see exactly what
> you mean (though I think I get the intention). Please provide one or two real
> examples of how it should (and shouldn't) be, to see if it can be fixed in the
> lang() call.
>
Again, thanks for your advice. I will learn to use lang() calls, then
hopefully, correct the situation.
>
> > > > 3) Strings too long(there is a max number?) or perhaps strings with
> > > > some special chars(c:\) can not be displayed in the translation
> > > > tool and in an application even if they are written in
> > > > phpgw_??.lang file.
> > >
> > > I havn't met such problems(or havn't noticed...^^||). Could you
> > > provide some exact information?
> > >
> >
> > in admin lang file:
> > http://host/egroupware/index.php?menuaction=developer_tools.uilangfile.edit&app_name=admin
> >
> > Enter the full path for temporary files.<br>Examples: /tmp, C:\TEMP
> >
> > Enter the full path for users and group files.<br>Examples: /files, E:\FILES
> >
> > These two lines can not be shown in the translation tool, but they are acutally saved in
> > the phpgw_ja.lang file.
>
>
> I can't reproduce that (I see it all in TT). I've tried my installation (with
> both spanish and japanese) and no problem at all. I guess it's something
> related to your installation, so try to replicate the problem in my
> installation.
It was not an installation issue. The problem was the TT not being
able to display "<br>例：" correctly: I added a space between "<br>"
and "例" in "add a new translation".
How to reproduce:
charset: Both in EUC-JP and UTF8
1. In Step 1
Source file: English
Translation file: Japanese
2. Enter the string with "<br>例："
3. Do the rest of steps
Result:
It seems that a "<br>" and the char are next to each other, it gets
jammed(called "moji-bake" in Japanese).
The English string/Japanese Translation string pair in the TT page was
not displayed.
Instead, The English string/empty pair is displayed, and additional
empty/translation pair as well.
Expected Result:
Show the English string/Japanese Translation string pair.
Workaround:
Add a space between "<br>" and the next char, then follow the steps in
TT.
>
> > I think there are other lines with the same problem in a different
> > app, but I can not search more today. Please allow me to report, if
> > any, later.
>
>
> Try to reproduce everything in my installation before reporting. Maybe it's
> just that utf-8 is needed and you haven't set it properly.
It happens in utf-8 as well, as described above.
Best regards.
Moritoshi Oshiro

Moritoshi Oshiro (m-ooshiro@...) escribi=C3=B3:
>
> Hi all.
>
>
> OK I found the following two parts in Calendar:
>
> http://host/index.php?menuaction=3Dcalendar.uiviews.day&date=3D20060616
>
> The first line in the right part of the page, it shows:
> (maybe $title variable?)
> calendar - Dayview: [userid] Lastname Firstname: Friday, 2006 6gatu 16
>
> Alos, in the left part of the page where the calendar menu is, it shows=
:
> (maybe javascrit part?)
> 6gatu 2006
>
>
> Above is in Dayview, and the same weird order exists in
> Day/Week/Monthview.
>
>
> My apology for not being able to point to the appropriate lines in a
> source file. If you could tell me exactly where those are in the
> source code, it would be very much appreciated. I really wanna learn
> egw and php.
I think there's no real need to dive into the php code, but lang() calls,=
as I
explained in my reply yesterday. Maybe if a "Japanese exclusive" date for=
mat
existed, then show it like that in the GUI (with the rest of d/m/y, etc
formats), but that would lead to "hardcode" the format, which is not
desirable.
Please study the lang calls examples I gave yesterday, in whose case I co=
uld
even fix that myself.
> Also, in Calender where you input a new plan in a small browser window:
>
> Owner [userid] Lastname FirstName Updated by
> ^^^^^^^^^^two tokens.
>
> They must be in one token for me to set a translated string in Japanese=
.
At this time, and surely due to variable font size, I can't see exactly w=
hat
you mean (though I think I get the intention). Please provide one or two =
real
examples of how it should (and shouldn't) be, to see if it can be fixed i=
n the
lang() call.
> > > 3) Strings too long(there is a max number?) or perhaps strings with
> > > some special chars(c:\) can not be displayed in the translation
> > > tool and in an application even if they are written in
> > > phpgw_??.lang file.
> >
> > I havn't met such problems(or havn't noticed...^^||). Could you
> > provide some exact information?
> >
>
> in admin lang file:
> http://host/egroupware/index.php?menuaction=3Ddeveloper_tools.uilangfil=
e.edit&app_name=3Dadmin
>
> Enter the full path for temporary files.<br>Examples: /tmp, C:\TEMP
>
> Enter the full path for users and group files.<br>Examples: /files, E:\=
FILES
>
> These two lines can not be shown in the translation tool, but they are =
acutally saved in
> the phpgw_ja.lang file.
I can't reproduce that (I see it all in TT). I've tried my installation (=
with
both spanish and japanese) and no problem at all. I guess it's something
related to your installation, so try to replicate the problem in my
installation.
> I think there are other lines with the same problem in a different
> app, but I can not search more today. Please allow me to report, if
> any, later.
Try to reproduce everything in my installation before reporting. Maybe it=
's
just that utf-8 is needed and you haven't set it properly.
Regards.

Hi all.
At Wed, 14 Jun 2006 10:07:27 +0800,
Finjon Kiang wrote:
>
> On 6/14/06, Moritoshi Oshiro <m-ooshiro@...> wrote:
> > Hello, All.
> >
> > Probably someone has already brought up the translation issues below,
> > but please allow me to show what I am aware of:
> >
> >
> > 1) date
> > In English, and probably in many other languages, the order of the
> > date is as follows:
> >
> > Monday, 24, June, 2006
> >
> > However, In Japanese, it must be as follws:
> >
> > 2006 June 24 Monday
> >
> > To complicate the problem more, we have to put a character after each
> > y/m/d. For instance it must be:
> >
> > 2006 nen 6 gatu 24 nichi Monday
> >
> > where "nen" is a kanji character meaning year, "gatu" meaning month,
> > and "nichi" meaning day.
> >
> > I believe it is the same in Chinese and perhaps in Korean as well.
> >
> > I have noticed that there are such cases in Calendar where the order
> > of date is not appropriate and there are no strings that can translate
> > the date with those additional characters in it.
>
> In preferences, you could change the default settings about this. But
> there are many positions which ignored by developers. I think we
> should submit some bug reports or patches to make it better. :)
>
> * Case by case instead of talk about it roughly.
OK I found the following two parts in Calendar:
http://host/index.php?menuaction=calendar.uiviews.day&date=20060616
The first line in the right part of the page, it shows:
(maybe $title variable?)
calendar - Dayview: [userid] Lastname Firstname: Friday, 2006 6gatu 16
Alos, in the left part of the page where the calendar menu is, it shows:
(maybe javascrit part?)
6gatu 2006
Above is in Dayview, and the same weird order exists in
Day/Week/Monthview.
My apology for not being able to point to the appropriate lines in a
source file. If you could tell me exactly where those are in the
source code, it would be very much appreciated. I really wanna learn
egw and php.
>
> >
> >
> > 2) preposition
> >
> > Prepositions such as "to", "in", "on", "at", and especially "by" can
> > be translate easily. However, when you compose a sentence/phrase by
> > putting together parts of the translated phrases, the whole
> > sentence/phrase becomes awkward. This is also due to the word order:
> >
> > For example, given the sentence "(This is) edited by user", and it has
> > three translation parts; "(This is) edited", "by", "user".
> >
> > If the order does not change, it will be translated as:
> >
> > "(Kore ha) hensyu sareta" "ni yotte" "user"
> > This is edited by user
> >
> > But, the right order in Japanese must be as follws:
> >
> > (Kore ha) user ni yotte hensyuu sareta.
> > This is user by edited.
> >
> >
> > Suggested resolution to the cases above:
> >
> > To avoid such problems, take the whole phrase/sentence to translate
> > (do not brake the string into several tokens).
>
> This problem had been talked before. It's better than several years
> before. There are always some improvements need to do. :)
Also, in Calender where you input a new plan in a small browser window:
Owner [userid] Lastname FirstName Updated by
^^^^^^^^^^two tokens.
They must be in one token for me to set a translated string in Japanese.
> > 3) Strings too long(there is a max number?) or perhaps strings with
> > some special chars(c:\) can not be displayed in the translation
> > tool and in an application even if they are written in
> > phpgw_??.lang file.
>
> I havn't met such problems(or havn't noticed...^^||). Could you
> provide some exact information?
>
in admin lang file:
http://host/egroupware/index.php?menuaction=developer_tools.uilangfile.edit&app_name=admin
Enter the full path for temporary files.<br>Examples: /tmp, C:\TEMP
Enter the full path for users and group files.<br>Examples: /files, E:\FILES
These two lines can not be shown in the translation tool, but they are acutally saved in the phpgw_ja.lang file.
I think there are other lines with the same problem in a different
app, but I can not search more today. Please allow me to report, if
any, later.
Thanks.
Moritoshi Oshiro
10art-ni Corporation

Robert Ludvik (r@...) escribi=C3=B3:
>
> Hi
> Why can't I choose Slovenian language on https://egw.omgs.net/login.php=
?
> Until recent it worked if I first login with en language selected, log
> out and login again with sl lang selected. If I login with en lang, I
> don't see our specisl characters correctly (C, S and Z with caron).
I don't know at this time. There are so many langs to be installed that I
might have (unintentionally, of course) discriminated any. I'll enable it
ASAP.
> And why login takes so much time? :-)
Well, that happens when somebody makes changes but doesn't update the db.
Then, when somebody logs in, egw (together with the option to search for =
new
phrases at login, which I have enabled) "updates" ALL languages in ALL ap=
ps,
and that's the reason of that big delay. As a quick workaround, I've enab=
led
by default to update the db (this is one of the many changes in the rewor=
ked
TT), which should prevent this behaviour (unless someone intentionally
unchecks it).
Regards.
PD: BTW, I've reset your password, because I think it was not working.

Hi
Why can't I choose Slovenian language on https://egw.omgs.net/login.php?
Until recent it worked if I first login with en language selected, log
out and login again with sl lang selected. If I login with en lang, I
don't see our specisl characters correctly (C, S and Z with caron).
And why login takes so much time? :-)
Thanks
Robert Ludvik

Moritoshi Oshiro (m-ooshiro@...) escribi=C3=B3:
>
> Hello, All.
>
> Probably someone has already brought up the translation issues below,
> but please allow me to show what I am aware of:
>
>
> 1) date
> In English, and probably in many other languages, the order of the
> date is as follows:
>
> Monday, 24, June, 2006
>
> However, In Japanese, it must be as follws:
>
> 2006 June 24 Monday
>
> To complicate the problem more, we have to put a character after each
> y/m/d. For instance it must be:
>
> 2006 nen 6 gatu 24 nichi Monday
>
> where "nen" is a kanji character meaning year, "gatu" meaning month,
> and "nichi" meaning day.
>
> I believe it is the same in Chinese and perhaps in Korean as well.
>
> I have noticed that there are such cases in Calendar where the order
> of date is not appropriate and there are no strings that can translate
> the date with those additional characters in it.
Well, the order of items (day, month, year) in dates is something that ha=
s to
be defined in every user's preferences (you can also set a global default
preference for all your users, though you can allow every user to overrid=
e
this setting).
A different issue is if in japanese (or others, I ignore) the date format=
has
more than three items, which has a different solution, and in this case m=
aybe
the handling of date formats has to be redesigned. Currently, there are a=
set
of values where the main difference is the separator (the order, too, but=
I'd
not say it's the main difference). So, maybe an approach like defining th=
e
separator and a kind of pattern can do the work. This latter is mostly an
issue for developers.
In the middle, there can be an easy solution, because translations are ha=
ndled
by the lang() function in phpgwapi, that can have up to 9 parameters. Thi=
s
means that by setting, for instance, the call with lang('month %1',month)
instead of just ('month') would allow you to translate it as '%1 gatu', '=
gatu'
or 'gatu %1' (you could change the order of the parameter or just ignore =
it).
> 2) preposition
>
> Prepositions such as "to", "in", "on", "at", and especially "by" can
> be translate easily. However, when you compose a sentence/phrase by
> putting together parts of the translated phrases, the whole
> sentence/phrase becomes awkward. This is also due to the word order:
>
> For example, given the sentence "(This is) edited by user", and it has
> three translation parts; "(This is) edited", "by", "user".
>
> If the order does not change, it will be translated as:
>
> "(Kore ha) hensyu sareta" "ni yotte" "user"
> This is edited by user
>
> But, the right order in Japanese must be as follws:
>
> (Kore ha) user ni yotte hensyuu sareta.
> This is user by edited.
>
>
> Suggested resolution to the cases above:
>
> To avoid such problems, take the whole phrase/sentence to translate
> (do not brake the string into several tokens).
Yes, that depends mostly on how the developer wrote the code. I think eve=
ry
case should be reported separately and specifying the app and phrase invo=
lved.
A more known case of that is the check installation screen in setup, wher=
e I
had to write a patch for the checks, because "writeable", "not", etc are
translated separately, and the later "rejoin" made only sense in english =
and
languages with that structure, but that didn't (at least) for spanish, fo=
r
example.
> 3) Strings too long(there is a max number?) or perhaps strings with
> some special chars(c:\) can not be displayed in the translation
> tool and in an application even if they are written in
> phpgw_??.lang file.
>
> I have not looked into the problem in depth, but there are several
> strings with such a problem.
I'd say that is a local installation problem, along with defining correct=
ly
the charset for the lang ('charset' phrase in phpgwapi). At this time, th=
e
defined for japanese is EUC-JP. You can test by entering the conflictive
characters as a translation of a string, save your file, leave that very
screen (no session nor cache) by hitting the cancel button (for example),=
go
back entering again (do not use the back function of the browser) and see=
if
the characters remain. If not, you can test by setting 'utf-8' in 'charse=
t' in
phpgwapi and try again. If you find you finally have to change the charse=
t
because the specified is wrong, then you have to backup and reinstall fro=
m
your backup specifying the new charset (unless you want to start from scr=
atch
or fix all wrong charsets by hand one by one).
Regards.

Finjon Kiang (kiange@...) escribi=C3=B3:
>
> Hello, Oscar.
>
> I met some problems when entering your site for translators. Did you
> receive my mail some days before??
>
Not sure at this time, but I'm replying using my installation remotely, s=
o you
should have no problem (unless you forgot your password or something simi=
lar).
If you still have problems, please mail me privately about it.
Regards.

At Wed, 14 Jun 2006 10:07:27 +0800,
Hi, Finjon.
> > I have noticed that there are such cases in Calendar where the order
> > of date is not appropriate and there are no strings that can translate
> > the date with those additional characters in it.
>
> In preferences, you could change the default settings about this. But
> there are many positions which ignored by developers. I think we
> should submit some bug reports or patches to make it better. :)
>
> * Case by case instead of talk about it roughly.
Thanks for your advice. I will try to do so case by case from now on.
>
> >
> >
> > 2) preposition
> > To avoid such problems, take the whole phrase/sentence to translate
> > (do not brake the string into several tokens).
>
> This problem had been talked before. It's better than several years
> before. There are always some improvements need to do. :)
Great! I want to contribute to make it better too!
>
> >
> >
> >
> > 3) Strings too long(there is a max number?) or perhaps strings with
> > some special chars(c:\) can not be displayed in the translation
> > tool and in an application even if they are written in
> > phpgw_??.lang file.
>
> I havn't met such problems(or havn't noticed...^^||). Could you
> provide some exact information?
>
Sure. Unfortunately, I can not work on egw right now. Please allow me
to get the exact information and post it later.
Regards,
Moritoshi Oshiro
10art-ni Corporation

On 6/14/06, Moritoshi Oshiro <m-ooshiro@...> wrote:
> Hello, All.
>
> Probably someone has already brought up the translation issues below,
> but please allow me to show what I am aware of:
>
>
> 1) date
> In English, and probably in many other languages, the order of the
> date is as follows:
>
> Monday, 24, June, 2006
>
> However, In Japanese, it must be as follws:
>
> 2006 June 24 Monday
>
> To complicate the problem more, we have to put a character after each
> y/m/d. For instance it must be:
>
> 2006 nen 6 gatu 24 nichi Monday
>
> where "nen" is a kanji character meaning year, "gatu" meaning month,
> and "nichi" meaning day.
>
> I believe it is the same in Chinese and perhaps in Korean as well.
>
> I have noticed that there are such cases in Calendar where the order
> of date is not appropriate and there are no strings that can translate
> the date with those additional characters in it.
In preferences, you could change the default settings about this. But
there are many positions which ignored by developers. I think we
should submit some bug reports or patches to make it better. :)
* Case by case instead of talk about it roughly.
>
>
> 2) preposition
>
> Prepositions such as "to", "in", "on", "at", and especially "by" can
> be translate easily. However, when you compose a sentence/phrase by
> putting together parts of the translated phrases, the whole
> sentence/phrase becomes awkward. This is also due to the word order:
>
> For example, given the sentence "(This is) edited by user", and it has
> three translation parts; "(This is) edited", "by", "user".
>
> If the order does not change, it will be translated as:
>
> "(Kore ha) hensyu sareta" "ni yotte" "user"
> This is edited by user
>
> But, the right order in Japanese must be as follws:
>
> (Kore ha) user ni yotte hensyuu sareta.
> This is user by edited.
>
>
> Suggested resolution to the cases above:
>
> To avoid such problems, take the whole phrase/sentence to translate
> (do not brake the string into several tokens).
This problem had been talked before. It's better than several years
before. There are always some improvements need to do. :)
>
>
>
> 3) Strings too long(there is a max number?) or perhaps strings with
> some special chars(c:\) can not be displayed in the translation
> tool and in an application even if they are written in
> phpgw_??.lang file.
I havn't met such problems(or havn't noticed...^^||). Could you
provide some exact information?
>
> I have not looked into the problem in depth, but there are several
> strings with such a problem.
>
>
> Enjoy.
>
>
> Moritoshi Oshiro
> 10art-ni Corporation
--
Finjon Kiang

Hello, All.
Probably someone has already brought up the translation issues below,
but please allow me to show what I am aware of:
1) date
In English, and probably in many other languages, the order of the
date is as follows:
Monday, 24, June, 2006
However, In Japanese, it must be as follws:
2006 June 24 Monday
To complicate the problem more, we have to put a character after each
y/m/d. For instance it must be:
2006 nen 6 gatu 24 nichi Monday
where "nen" is a kanji character meaning year, "gatu" meaning month,
and "nichi" meaning day.
I believe it is the same in Chinese and perhaps in Korean as well.
I have noticed that there are such cases in Calendar where the order
of date is not appropriate and there are no strings that can translate
the date with those additional characters in it.
2) preposition
Prepositions such as "to", "in", "on", "at", and especially "by" can
be translate easily. However, when you compose a sentence/phrase by
putting together parts of the translated phrases, the whole
sentence/phrase becomes awkward. This is also due to the word order:
For example, given the sentence "(This is) edited by user", and it has
three translation parts; "(This is) edited", "by", "user".
If the order does not change, it will be translated as:
"(Kore ha) hensyu sareta" "ni yotte" "user"
This is edited by user
But, the right order in Japanese must be as follws:
(Kore ha) user ni yotte hensyuu sareta.
This is user by edited.
Suggested resolution to the cases above:
To avoid such problems, take the whole phrase/sentence to translate
(do not brake the string into several tokens).
3) Strings too long(there is a max number?) or perhaps strings with
some special chars(c:\) can not be displayed in the translation
tool and in an application even if they are written in
phpgw_??.lang file.
I have not looked into the problem in depth, but there are several
strings with such a problem.
Enjoy.
Moritoshi Oshiro
10art-ni Corporation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, all.
As some of you may know, I'm working in (what I consider) a lot of
improvements for translation tools. I didn't formally request to take
over the maintenance of it because I'm still learning egw internals
These changes will be available in the development (aka trunk or HEAD)
branch as soon a core developer places some necessary changes in the api
that I've requested, and I would update the rest of the changes for the
new translation tools to work. Don't expect it to be available in any
1.2.x release (because it's a _stable_ release, aimed to fix bugs only,
not to include new features or major changes).
There isn't a _100%_ clean and accurate info about the changes and some
things into my mind, but I have what I think is a "good" draft with the
status of the written features and, at least, more expected changes. I
think this draft covers about 90% of the data, so I think it's very good
for a first approach of the idea. Here's a copy & paste of it:
=3D=3D=3D=3D=3D=3D=3D=3D BEGINNING OF PASTE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Enhancements for translations tools 1.3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This new rework of translation tools has as main core the rewrite of the
table structure that handles translations, being the main point to
reduce the impact in the db by assigning numeric ids instead of long and
"expensive" varchars up to 128 bytes length. The new table structure of
the affected tables is this:
'egw_lang_en' =3D> array(
'fd' =3D> array(
'content_id' =3D> array('type' =3D> 'auto','precision' =3D>
'11','nullable' =3D> False),
'app_name' =3D> array('type' =3D> 'varchar','precision' =3D>
'32','nullable' =3D> False),
'parent_app_name' =3D> array('type' =3D> 'varchar','precision' =
=3D>
'32','nullable' =3D> False),
'message_id' =3D> array('type' =3D> 'varchar','precision' =3D>
'128','nullable' =3D> False)
),
'pk' =3D> array('content_id'),
'fk' =3D> array(),
'ix' =3D> array(),
'uc' =3D> array(array('app_name','message_id'))
)
'egw_lang' =3D> array(
'fd' =3D> array(
'lang' =3D> array('type' =3D> 'varchar','precision' =3D>
'5','nullable' =3D> False,'default' =3D> ''),
'content_id' =3D> array('type' =3D> 'int','precision' =3D>
'11','nullable' =3D> False),
'content' =3D> array('type' =3D> 'text','nullable' =3D> False)
),
'pk' =3D> array('lang','content_id'),
'fk' =3D> array(),
'ix' =3D> array(),
'uc' =3D> array()
),
The egw_lang_en table uses the numeric content_id field to assign
numeric ids to every message_id. The fields are:
- parent_app_name: the directory where the file is originally read
- "app_name": exactly the same, being one of $parent_app_name, 'admin',
'common', 'preferences' or 'login'. Maybe all values not being
$parent_app_name could be handled by using only 'common', but that is
not crucial at this time. It is taken from the second field in the
phpgw_en.lang file.
- message_id: exactly the same, a string up to MAX_MESSAGE_ID_LENGTH
characters (currently 128) that contains the 'entity' to be translated,
taken from the first field in the phpgw_en.lang file. The current role
is to initially identify the source string, and assign a numeric id to
that string inside the parent_app_name (there could be two uses or
contexts of the same message_id in the different parent_app_name, but
NOT in the same app_name -i.e. 'common'-).
- content_id: the main philosophy behind is to have referencial
integrity in the lang table. A translated string is now identified in
the db by the content_id (currently automatically assigned by the db
engine when inserting a message_id), the lang and the translation itself
('content' fieldname), avoiding the previous schema of "uncontrolled"
and accumulated strings, because indexing several columns doesn't
prevent unused strings, along with unnecesary long rows (and there are
more than 7000 message_id, or strings per language). This field in the
language table uses the same field in the id table as foreign key.
When the new table structure is implemented in head (1.3.x), then it
will be possible to port this rework to public (doing it right now would
break the current translation tools). Also, this needs to work in
conjunction with the translation class, that is affected by these changes=
.
Below is my working (draft?) to keep track, together with the status
between parenthesis.
New features
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- - (TESTING) Enhancement of the display of the "Application: <app>" bein=
g
translated. It's usual to "forget" the app being translated, and
sometimes there's no easy way to find out. The current fix is enhancing
by using an <h3> title, and duplicate it at the bottom of the strings.
- - Add comment support for phrases (developers, please use this by givin=
g
hints about context to help translators!!):
- (FIXED) Parsing and writing comment line(s) in egw_en.lang file
- UI for editing comment (FIXED - using javascript prompt() function).
TODO: replace current javascript prompt() with a subform, like calendar
entries.
- (FIXED) Show the comment in the UI (useful for devs and translators)
- (TODO) Use ACL to allow edit comments and write english files
- - (TESTING) Rename or rewrite of existing functions for better
comprension / management. Also, get rid of outdated, unused or
duplicated functions, tags, etc from developer tools:
- (TESTING)A wrong function in phpgwapi/inc/common_functions.inc.php
uses the phpgw_lang table, but it seems it's not used.
- (DONE) Rename 'Save', 'Update' and button names in the edit app screen=
.
- (DONE) Take a lot of code in uilangfile.edit to bolangfile, because
there are no UI functions.
- - (DONE) Reduce source language list to installed langs. This fixes the
load of source language.
- - (TESTING) Improve statistics module in site manager
- - (DONE) New phrases added at top of the page rather than at alphabetic
location. When writing, they're properly sorted. Test comments.
- - (DONE) Prevent file overwrites of the lang file if the content doesn'=
t
differ
- - (DONE) Update db button checked by default
- - (FIXED) Allow searches and uploads to be translated before being adde=
d
to the whole translation
- - Take some screens to popup (as calendar entries). The target is to no=
t
lose the edit screen, always useful:
- Add phrase
- Search missing phrases
- Upload file
- - (FIXED) Show times langs take to be installed when enabling extra
messages. This affects setup/lang.php.
- - (DONE) Add upload feature
- - (DONE) Show in the main screen the status of every app (graph just
like statistics)
Intermediate tasks to get the desired final result, ordered by theorical
priority:
High
=3D=3D=3D=3D
- - (FIXED) Use the new table schema, along with all the necessary files
for installation or upgrade. The new table name containing the
message_id's is "egw_lang_en", so if you think of another table name,
the sooner, the better :).
- - (DONE) Include the content_id field, (FIXED)trying to use it
- - (FIXED) Find a way to link 'common' with the source app. This has bee=
n
done by adding a 'parent_app_name' field in the "egw_lang_en" table,
containg the app (EGW_ROOT/app/phpgw_en.lang) the message_id belongs to.
Again, the sooner the better for changing the field name. This small
field is very useful to improve searches logic.
- - (TESTING) Check for the langfiles to be writable at every load,
warning about it
- - (LATER) Make install or uninstall the selected apps only in /setup,
instead of reinstall all apps
- - (TESTING) Make sure every parent_app_name has itself as
parent_app_name and common as app_name, removing from phpgwapi (or any
other)
Medium
=3D=3D=3D=3D=3D=3D
- - Add admin options:
- Type of language load:
* Full load (default, merge source file + db + search phrases,
syncing all phrases)
* Source + db (no search phrases). Current default.
* Db only
* Source only
- Use ACL. Default not write english file
- Try to make the 'search new phrases' useless by performing it at
load time.
- - (FIXED) Sync the add and delete actions with all languages installed
- - Search for global/per app untranslated phrases
- - Integrate paging. Get the globalpreference for the number of lines.
- - Separate sub-apps like htmlarea, jscalendar and others. The best mayb=
e
a subdir in setup with the sub-app name itself.
Low
=3D=3D=3D
- - Edit of global missing strings in the same screen (with a threshold)
- - (TESTING)Walk to egw_$lang.lang naming convention. (DONE)The
EGW_LANGFILE_PREFIX constant has been defined in both
setup/inc/class.setup_translation.inc.php and in translation class, but
current value is still 'phpgw_'. This affects setup/inc.
- - Autotranslation capabilities or search for existing similar phrases.
- - Move "loginscreen" and "mainscreen" to somewhere else (maybe config),
because they're not apps
- - Split mutisentences phrases into single sentences.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D END OF PASTE =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
I hope your comments about all this. The installation is at
http://www.omgs.net/~oscar/egroupware/, but your accounts (nor any demo
account) aren't available yet. Anyway, at least at this time, this
installation isn't intended to commit changes to 1.2 branch, but to test
the new translation tools, and help to debug your own translations.
Regards.
- --
|----------------------------------------------------------------------|
| http://counter.li.org info: Linux user: 92390 - Linux machine: 39301 |
| Oscar Manuel G=F3mez Senovilla - omgsATescomposlinux.org =
|
| GPG Key at http://pgp.escomposlinux.org |
|----------------------------------------------------------------------|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEjcBDQpr3kykd/aQRAjpYAJ9uPXUacNUnBsWNlbKMwVFnlsC1jwCfbymF
YKA3jkqAoeEDe1YwsT1uZPg=3D
=3DNXCD
-----END PGP SIGNATURE-----

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details