Hi Bob,
On Fri, Oct 7, 2011 at 1:46 PM, Robert Hanson <hans...@stolaf.edu> wrote:
> Nico,
>
> I like the [[ ]] idea.
>
> How have you been working the translations in terms of the two "open"
> versions -- in this case 12.2 and 12.3? Is it always duplicated for the
> two projects? I think if you want to do the .po replacements, maybe you
> should also do the .java changes as well, so that it is all done at once,
> and one update from your work updates the rest of us. Otherwise we are going
> to risk getting out of sync.
>
With launchpad, I can set up branches for translations and synchronize them
with a SVN branch.
I setup launchpad so that translations are done by default on the trunk
(12.3 now).
But I think launchpad also update automatically some translations from one
branch to an other.
Each time I see modifications in launchpad for the trunk, I retrieve them
and commit them in SVN. For other branches, I only retrieve them from time
to time.
Since 12.3 and 12.2 are quite similar right now, I haven't setup a 12.2
branch for translations yet. I will do this some time later.
Yes, for the change, it's better to do .java and .po files simultaneously to
avoid troubles and loosing translations in the process.
That's why I was suggesting to tell me what English strings should be
changed and to what.
>
> Here's another idea: How about a little Perl script that would do all
> replacements at once -- it's the same in the Java as the .po files, so we
> could just say, "Change this phrase throughout the project -- .po and .java
> files." (Perhaps with a preview.) Then any of us could do that -- but
> preferably you :). Maybe give it a list of changes:
>
If anyone can write that script, it's really ok for me, but I think the
replacements can also be done quite easily with tools like notepad++ (find
and replace in a bunch of files). No need for preview, I will do the
replacements and see with SVN what changes have been done
before committing them.
> Top ==> Top [[as in "view from the top]]
> Bottom ==> Bottom [[ as in "view from the bottom"]]
>
> It definitely won't matter if translators keep or remove the [[ ]] -- we
> will have to check for those anyway.
>
Yes.
>
> Bob
>
>
> On Fri, Oct 7, 2011 at 6:26 AM, Nicolas Vervelle <nverve...@gmail.com>wrote:
>
>> Hi Bob,
>>
>> I thought again about this translation business. What is the current
>> status ?
>> If I understood correctly :
>>
>> - There's 1 text having a [...] that should be kept in the displayed
>> text ("bad [R, G, B] color")
>> - 1 or 2 texts having a [...] that should be removed in the displayed
>> text
>> - The code removes [...] in the displayed text when it is at the
>> beginning or the end of the text
>>
>> I would suggest an other approach :
>>
>> - Using [[...]] instead of [[...]] for text that should be removed in
>> the displayed text. This is really unlikely that we would need a text with
>> that construction.
>> - Replacing the 1 or 2 texts having a [...] that should be removed by
>> the [[...]] construction
>> - The translated text can keep the [[...]] part or remove it
>> - Modifying the code for removing [[...]] in the displayed text
>> wherever it is
>>
>> For making current English texts more explicit, I suggest the following
>> approach :
>>
>> - Tell me which English texts need to be modified and by what they
>> should be replaced
>> - I will change the Java code and the existing .po files so that we
>> can keep the existing translations (it should be a simple matter of
>> finding/replacing text in all the .po files)
>> - Launchpad will update itself automatically when I commit the Java
>> files and the .po
>>
>> What do you think ?
>>
>> Nico
>>
>>
>> On Tue, Oct 4, 2011 at 2:18 PM, Robert Hanson <hans...@stolaf.edu> wrote:
>>
>>> I've at least put in the [....] business (starting or end of line) for
>>> Jmol 12.3.1. I saw there was one already in there anyway.
>>>
>>>
>>> 2011/10/4 Angel Herráez <angel.herr...@uah.es>
>>>
>>>> In my opinion, being able to make distinctions between phrases that
>>>> translate different. There are a few other instances that I would
>>>> like to improve in the future (like no, none, ...)
>>>>
>>>> It is of course clear that we need a mechanism that does not break
>>>> existing translation and requires the least of custom per-case
>>>> editing (which is what we suffer now)
>>>>
>>>> We can discuss choices without a hurry, for 12.3
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure contains a
>>>> definitive record of customers, application performance, security
>>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>>> sense of it. Business sense. IT sense. Common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>> _______________________________________________
>>>> Jmol-developers mailing list
>>>> Jmol-developers@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>>
>>>
>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Professor of Chemistry
>>> St. Olaf College
>>> 1520 St. Olaf Ave.
>>> Northfield, MN 55057
>>> http://www.stolaf.edu/people/hansonr
>>> phone: 507-786-3107
>>>
>>>
>>> If nature does not answer first what we want,
>>> it is better to take what answer we get.
>>>
>>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> Jmol-developers mailing list
>>> Jmol-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>>
>> _______________________________________________
>> Jmol-developers mailing list
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>>
>
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
