phpicalendar-devel

[PHPiCalendar-DEV] Translations

[Greg W. <gr...@gr...>]

I was just reading through the Japanese translation, because I was
thinking about updating it to include all the new 0.9 stuff, when I
realized that we might need to rethink the way in which we do
translations, because not all languages use the same syntax as English.
For example, with the "RSS-enabled" text, the footer.inc.php file writes
$this_site_is_lang and then the link that says "RSS-Enabled".  That works
out find in English, because you get "This site is RSS-Enabled".  But in
Japanese, the sentence structure (at least in the sentence Jared used) is
such that the PHP would have to write some Japanese before RSS-Enabled,
and some after.  As it is, it says something more like "This site is.
RSS-Enabled", which sounds almost right in English because it just looks
like stray punctuation, but it's totally wrong in Japanese.

As a fix for this particular issue, I'd suggest that "kono uebusaito ha
desu." simply have the "desu." removed from the end, for the
$this_site_is_lang variable.  That would make things gramatically correct.
(I can't figure out how to edit the file properly, or I'd do it myself...
I can't get it to show up as Japanese in any text editor)  But this speaks
to the larger issue of not always being able to rely on the sentence
structure being the same in other languages.  What do you think we should
do to fix this?  I suppose one way would be to use functions rather than
variables, and so for example calling rss_enabled_lang() would write the
entire sentence plus link based on the language.  I would think that if we
do that, we'll want the functions to return PHP code that can then be
interpreted in the file that calls the function, rather than returning the
final HTML code, as then we don't have to deal with variable scope or
variable passing.

Am I making any sense?  What does everyone else think?  Maybe this isn't a
big enough issue to worry about right now, but it's something to think
about...

Greg

P.S.  Jared, if you could tell me how to edit that file properly, it would
be much appreciated.  I generally use BBEdit for stuff like this that I
can't do in vim, and can write, save, and reopen files containing
Japanese, but for some reason just see gibberish in place of Japanese when
I open japanese.inc.php.  Thanks!

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

Re: [PHPiCalendar-DEV] Translations

[Jared <xe...@si...>]

I'd be happy to have you help with the Japanese translation. I haven't 
had a chance to do it all myself yet. On top of that, I'm still 
learning and am not fluent. However, the bug you noticed it something I 
meant to fix. I know how, and it's relatively simple, I just haven't 
done it yet. Anything that is a sentence must be done this way (and in 
most cases, it is).

The variable should be set to something like: "This site is %s." in 
English, and "kono webusaitoha %s des." and then run it through 
sprintf(). That's how I handle things like the error messages and the 
number of seconds the search took. I mean to change this for that, but 
I forgot. Oops.

I also have part of 0.9 translations done so I'll commit those now. To 
read it, go to the open dialog of BBEdit and chose UTF-8 as the 
encoding, then open it. Without the byte-order mark, you must do this. 
If we included the byte-order mark it would be OK to just double click 
it but then there would be an extra character at the top of the web 
site because the browser doesn't know what else to do with it. It's a 
small price to pay, I think.

Please let me know what else can be fixed. I know my Japanese isn't 
very good so I'd be happy to have help. The people I get help from are 
technologically illiterate and I'm afraid that makes things difficult 
to translate at times.

Thanks.

-Jared

On Sunday, December 15, 2002, at 10:35 AM, Greg Westin wrote:

> I was just reading through the Japanese translation, because I was
> thinking about updating it to include all the new 0.9 stuff, when I
> realized that we might need to rethink the way in which we do
> translations, because not all languages use the same syntax as English.
> For example, with the "RSS-enabled" text, the footer.inc.php file 
> writes
> $this_site_is_lang and then the link that says "RSS-Enabled".  That 
> works
> out find in English, because you get "This site is RSS-Enabled".  But 
> in
> Japanese, the sentence structure (at least in the sentence Jared used) 
> is
> such that the PHP would have to write some Japanese before RSS-Enabled,
> and some after.  As it is, it says something more like "This site is.
> RSS-Enabled", which sounds almost right in English because it just 
> looks
> like stray punctuation, but it's totally wrong in Japanese.
>
> As a fix for this particular issue, I'd suggest that "kono uebusaito ha
> desu." simply have the "desu." removed from the end, for the
> $this_site_is_lang variable.  That would make things gramatically 
> correct.
> (I can't figure out how to edit the file properly, or I'd do it 
> myself...
> I can't get it to show up as Japanese in any text editor)  But this 
> speaks
> to the larger issue of not always being able to rely on the sentence
> structure being the same in other languages.  What do you think we 
> should
> do to fix this?  I suppose one way would be to use functions rather 
> than
> variables, and so for example calling rss_enabled_lang() would write 
> the
> entire sentence plus link based on the language.  I would think that 
> if we
> do that, we'll want the functions to return PHP code that can then be
> interpreted in the file that calls the function, rather than returning 
> the
> final HTML code, as then we don't have to deal with variable scope or
> variable passing.
>
> Am I making any sense?  What does everyone else think?  Maybe this 
> isn't a
> big enough issue to worry about right now, but it's something to think
> about...
>
> Greg
>
> P.S.  Jared, if you could tell me how to edit that file properly, it 
> would
> be much appreciated.  I generally use BBEdit for stuff like this that I
> can't do in vim, and can write, save, and reopen files containing
> Japanese, but for some reason just see gibberish in place of Japanese 
> when
> I open japanese.inc.php.  Thanks!
>
> ---
> gr...@gr...
> http://www.gregwestin.com/
> Contact info: http://www.gregwestin.com/contact.php
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel

Re: [PHPiCalendar-DEV] Translations

[Greg W. <gr...@gr...>]

This should fill in the blanks in the Japanese translation.  I can't
guarantee that they're right, as I haven't used a computer with Japanese
programs and whatnot for a couple years, but at least they work for now...

Greg

---
gr...@gr...
http://www.gregwestin.com/
Contact info: http://www.gregwestin.com/contact.php

On Sun, 15 Dec 2002, Jared wrote:

> I'd be happy to have you help with the Japanese translation. I haven't
> had a chance to do it all myself yet. On top of that, I'm still
> learning and am not fluent. However, the bug you noticed it something I
> meant to fix. I know how, and it's relatively simple, I just haven't
> done it yet. Anything that is a sentence must be done this way (and in
> most cases, it is).
>
> The variable should be set to something like: "This site is %s." in
> English, and "kono webusaitoha %s des." and then run it through
> sprintf(). That's how I handle things like the error messages and the
> number of seconds the search took. I mean to change this for that, but
> I forgot. Oops.
>
> I also have part of 0.9 translations done so I'll commit those now. To
> read it, go to the open dialog of BBEdit and chose UTF-8 as the
> encoding, then open it. Without the byte-order mark, you must do this.
> If we included the byte-order mark it would be OK to just double click
> it but then there would be an extra character at the top of the web
> site because the browser doesn't know what else to do with it. It's a
> small price to pay, I think.
>
> Please let me know what else can be fixed. I know my Japanese isn't
> very good so I'd be happy to have help. The people I get help from are
> technologically illiterate and I'm afraid that makes things difficult
> to translate at times.
>
> Thanks.
>
> -Jared
>
> On Sunday, December 15, 2002, at 10:35 AM, Greg Westin wrote:
>
> > I was just reading through the Japanese translation, because I was
> > thinking about updating it to include all the new 0.9 stuff, when I
> > realized that we might need to rethink the way in which we do
> > translations, because not all languages use the same syntax as English.
> > For example, with the "RSS-enabled" text, the footer.inc.php file
> > writes
> > $this_site_is_lang and then the link that says "RSS-Enabled".  That
> > works
> > out find in English, because you get "This site is RSS-Enabled".  But
> > in
> > Japanese, the sentence structure (at least in the sentence Jared used)
> > is
> > such that the PHP would have to write some Japanese before RSS-Enabled,
> > and some after.  As it is, it says something more like "This site is.
> > RSS-Enabled", which sounds almost right in English because it just
> > looks
> > like stray punctuation, but it's totally wrong in Japanese.
> >
> > As a fix for this particular issue, I'd suggest that "kono uebusaito ha
> > desu." simply have the "desu." removed from the end, for the
> > $this_site_is_lang variable.  That would make things gramatically
> > correct.
> > (I can't figure out how to edit the file properly, or I'd do it
> > myself...
> > I can't get it to show up as Japanese in any text editor)  But this
> > speaks
> > to the larger issue of not always being able to rely on the sentence
> > structure being the same in other languages.  What do you think we
> > should
> > do to fix this?  I suppose one way would be to use functions rather
> > than
> > variables, and so for example calling rss_enabled_lang() would write
> > the
> > entire sentence plus link based on the language.  I would think that
> > if we
> > do that, we'll want the functions to return PHP code that can then be
> > interpreted in the file that calls the function, rather than returning
> > the
> > final HTML code, as then we don't have to deal with variable scope or
> > variable passing.
> >
> > Am I making any sense?  What does everyone else think?  Maybe this
> > isn't a
> > big enough issue to worry about right now, but it's something to think
> > about...
> >
> > Greg
> >
> > P.S.  Jared, if you could tell me how to edit that file properly, it
> > would
> > be much appreciated.  I generally use BBEdit for stuff like this that I
> > can't do in vim, and can write, save, and reopen files containing
> > Japanese, but for some reason just see gibberish in place of Japanese
> > when
> > I open japanese.inc.php.  Thanks!
> >
> > ---
> > gr...@gr...
> > http://www.gregwestin.com/
> > Contact info: http://www.gregwestin.com/contact.php
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Phpicalendar-devel mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
>