Please login or register to participate.
Discussion
.
suiato Jan 10, 2010 10:45 AM
Segmentation in i18n needs more care.
Replies (15)
suiato Jan 10, 2010 11:00 AM
For example, in navigation.pt:44,
<span class="navaddnewheader"><tal:translate i18n:translate="">Add a new</tal:translate> <tal:replace tal:replace="menuitem/title" /></span>
becomes Add a new Smart Collection in English. But, in Japanese, the order of words goes like a new Smart Collection add, i.e., 新しいスマート・コレクションを追加する。In the current segmentation of i18n above, changing the order of words in accordance with the Japanese word order is not possible.
suiato Jan 11, 2010 05:25 PM
In this particular case, I managed by translating it as 新規追加: , i.e., New addition: , but these tricks may not work all the time.
dhiraj Jan 12, 2010 10:24 PM
Hmm... I see your point. Yes, that's a mistake.

I'm thinking the correct markup would have been like this?
<span class="navaddnewheader" i18n:translate="add_new_content_type">Add a new <tal:content tal:replace="menuitem/title" i18n:name="content_type_name"/></span>

The above would have given you the flexibility you needed, yes?
suiato: You now have commit rights on Cyn.in translation SVN. If you're doing buildout, then commit in i18n folder should now work with the same username and password as Cynapse Community site. If not, SVN url is: http://odn.cynapse.com/svn/cynintranslations/trunk


Also added issue for above at http://odn.cynapse.com/issues/1271
You can also now watch and submit new issues about Cyn.in Translations here: http://odn.cynapse.com/projects/cynintranslations/issues

Please point out / suggest template fixes or patch *wherever* you get a problem, we'll fix this! :)
If it becomes too tedious to maintain individual issues, and there are too many places where you need variables instead of static placement, then we can even start a thread somewhere with just template and line number and get them all.

Thanks for helping out with the Japanese translation, appreciate it! :)
suiato Jan 13, 2010 02:52 AM
Thanks, Dhiraj, for commenting and giving me the right to commit translation. I will try my best to contribute and be responsible in my commitment while working and consulting with the Cynin team and this group.
--
Teru
suiato Jan 15, 2010 07:26 AM
I'd like to take some steps to improve the translation of cyn.in into Japanese.

First is to know the current status: cynin-ja.po is incomplete and unusable in practice with a mixture of terrible automatic translation and often-inmature manual translation. I'd like people to realize that automatic translation of English to Japanese like the one offered by Google is an interesting effort, but still has a long way to be usable in real life. The situation is much different from translating English to German, Italian or some other cousins of European languages in terms of grammer, terms, characters, etc.

So, the second step is to improve cynin-ja.po by manually translating it. Because of the current situation described above, it requires reviewing and re-translating most of the terms. I have done this part mostly, and plan to submit the file after checking how it shows up in an example site and fine-tuning.

As I mentioned in my previous post, there are cases where inappropriate segmentation hampers proper translation. As suggested by Dhiraj, I will make a list of these cases to point them out as the third step. Correcting it requires changing the source code, and I wonder if this is better done in a branch of the repository. I expect committers will make a right decision.

Besides cynin.pot, I understand there are other translation files mainly originating from Plone projects/products. Although I have tried to improve them for the ones with *-ja.po, I wonder if these modifications need to be submitted to the Plone translation team rather than to the cynin team. There might be more files remainig to be translated into Japanese. I'd like to consult with the cynin team and the Plone team when I get to this forth step.

I'll appreciate comments regarding these steps for Japanese translation.

--
Teru
dhiraj Jan 15, 2010 09:47 AM
Yes, your thoughts are spot-on, you are on the right track! :)

This was a known issue going in into the auto-translation that we agreed to within ourselves. Having auto-translated results in a sub-optimal translation for non-latin based languages, because the Google Translate API is not up to the mark yet, for these. But it was a conscious decision that we took, basically having a bad translation was better than *no* translation.

For the translation strings that are not part of cynin-ja.po there are 2 approaches that you can take. For your own use you can use the i18noverride based folder, to override any translation file that you want to. For example, say you want to override plone-ja.po, you can easily place it into the plone-i18n-overrides folder. You'll find this next to the i18n folder (in cynintrunk\src\ubify.policy\ubify\policy folder). Any .po file you place into this folder and re-buildout, will be copied to the top level zope during the buildout process. This will let you override any file you want to, even of products that are not part of core plone, simply copy the existing file that you find into this folder and translate as required. We've already put a sample plone-hi.po file in this folder as an example of doing this override. Of course, once you're satisfied with the extended translation in this file, the correct thing to do is to submit it to Plone translation team, or the developer of the particular product that you're translating - they may take some time to review and accept it for usage directly within the product itself. In either case you should submit it to Cyn.in as well, that way at least all Cyn.in users will get the benefit of it immediately.
suiato Jan 16, 2010 09:32 AM
Thanks, Dhiraj. Good to know about override.

Tried to commit, but failed. Following is its log. Am I missing something? Will appreciate your advice.

cynin@andromeda:~/cynin_trunk/src/ubify.policy/ubify/policy/i18n$ svn status
M cynin-ja.po
cynin@andromeda:~/cynin_trunk/src/ubify.policy/ubify/policy/i18n$ svn commit -m "revised cynin-ja.po. manual, thorough translation."
Authentication realm: <http://odn.cynapse.com:80> redmine
Password for 'cynin': # I hit return here.
Authentication realm: <http://odn.cynapse.com:80> redmine
Username: suiato
Password for 'suiato': ********
Authentication realm: <http://odn.cynapse.com:80> redmine
Username: suiato
Password for 'suiato': ********
svn: Commit failed (details follow):
svn: MKACTIVITY of '/svn/cynintranslations/!svn/act/bb632865-e19c-46b1-ae6a-1158d78508e7': authorization failed: Could not authenticate to server: rejected Basic challenge (http://odn.cynapse.com)

--
Teru
dhiraj Jan 16, 2010 11:44 AM
Hmm... this seems to be a problem in our SSO with regards to SVN passwords. Sent you a password change email separately at your signed up email.

We'll fix this soon. :(
suiato Jan 16, 2010 02:32 PM
Thanks, it wotked! :)
Just committed a revised cynin-ja.po to the repository.
--
Teru
suiato Jan 13, 2010 06:41 AM
Apart from the topics in this thread, I just noticed that the time displayed beside a user name in each post was in GMT. Nine hours of difference from JST in Japan (checked with IE, Firefox and Safari on Windows). Perhaps, it's better to indicate it by adding "(in GMT)" as a translatable string after the time, to avoid unnecessary confusion.

I also noticed that, when using Firefox 3.0 on Ubuntu 9.04, the display somehow showed a time period instead of a time in GMT itself. For examle, it showed "suiato about 9 hours ago" right after I posted :-o
I haven't found how it happens... perhaps it did because of the settings of my PC? Time display in Gmail is OK, though...

Hope there'll be some improvement in the future.
--
Teru
dhiraj Jan 13, 2010 08:28 AM
Hmm... that's several different issues. :)

Short answer is this: There's nothing wrong with your timezone settings - the Cyn.in server needs to be told to run in whatever timezone you're in, and then you'll get to see the x minutes ago strings as well! :)

1: The x hours ago thing was originally developed with the intention of having user-settable timezones (http://odn.cynapse.com/issues/592) but this is yet to be implemented.

2. The x hours ago is also caching language currently (javascript variables (including current language) are being cached on server side), this causes a problem where userA is viewing site in Japanese, userB is viewing the site in Engligh, then sometimes userB gets the x hours ago in Japanese. This is at: http://odn.cynapse.com/issues/1238

3. Showing GMT next to the time .... for this we'll have to disable showing of the x hours ago thing and show the plain-old date string, no? Also, it's not really "assumable" to be GMT always - it could be any timezone, there's a way to set it in buildout.cfg / zope.conf, so this would have to be accounted for, as well.

Overall I'd vote that we take the time required to make the per-user timezone setting in user-profile thing. It would solve a major part of the issues with this. And it would be going.... forward instead of the current half-way implementation. :(
suiato Jan 15, 2010 06:27 AM
Thanks, Dhiraj for detailed explanation. Well, I understand that this issue seems to be more complicated than I thought. I second your vote for "per-user timezone setting in user-profile thing". It'd be nice :)
dhiraj Jan 19, 2010 10:35 PM
suiato: Have a look at the discussion at http://www.cynapse.com/comm[…]-us-central-time.-could-you

We're discussing a fix for the time zone issue, I think this will apply to you as well.
noname Jul 15, 2010 11:20 PM
hi, i've just recently begun evaluating your product. really like what i see so far but am facing similar issues with the time stamps being recorded. I installed cyn.in from the ISO cd installer, as a virtual machine. I initially had issues just getting the time showing correct within the o/s. Have it set to Central Standard time using 'SystemV/CST6'. I had a look at the discussion you referenced above and followed through step by step, adding the environment section using 'TZ SystemV/CST6', doing a re-buildout, etc. I have a pretty default set up currently only have 3 spaces added.

Adding a new discussion and viewing it from the spaces 'dashboard view' shows the correct time - it shows 'last created by ..., July 15, 2010 3:10pm for example. If I switch the the application view: discussions board, I again see the correct date-time stamp information. The problem is when I click on the discussion item itself to take me to the detailed view. On this view (on the view tab) at the top it shows the date-time stamp 1 hour ahead as Jul 15, 2010 04:10 PM. And look at the details below it shows created by ..., July 15, 2010 4:40pm (again incorrect at 1 hour ahead) and shows 'Last Activity' correctly at 3:10pm.

It's making no sense to me why timestamps should be so mixed up :(

I've also tried defining TZ=SystemV/CST6 in the zopectl startup script (./parts/instance/bin/zopectl) with no luck as well.

Hoping you can provide a suggestion/solution. Without a fix this will be a deal breaker for us.
noname Jul 15, 2010 11:20 PM
hi, i've just recently begun evaluating your product. really like what i see so far but am facing similar issues with the time stamps being recorded. I installed cyn.in from the ISO cd installer, as a virtual machine. I initially had issues just getting the time showing correct within the o/s. Have it set to Central Standard time using 'SystemV/CST6'. I had a look at the discussion you referenced above and followed through step by step, adding the environment section using 'TZ SystemV/CST6', doing a re-buildout, etc. I have a pretty default set up currently only have 3 spaces added.

Adding a new discussion and viewing it from the spaces 'dashboard view' shows the correct time - it shows 'last created by ..., July 15, 2010 3:10pm for example. If I switch the the application view: discussions board, I again see the correct date-time stamp information. The problem is when I click on the discussion item itself to take me to the detailed view. On this view (on the view tab) at the top it shows the date-time stamp 1 hour ahead as Jul 15, 2010 04:10 PM. And look at the details below it shows created by ..., July 15, 2010 4:40pm (again incorrect at 1 hour ahead) and shows 'Last Activity' correctly at 3:10pm.

It's making no sense to me why timestamps should be so mixed up :(

I've also tried defining TZ=SystemV/CST6 in the zopectl startup script (./parts/instance/bin/zopectl) with no luck as well.

Hoping you can provide a suggestion/solution. Without a fix this will be a deal breaker for us.
 
Loading