[OPEN-ILS-GENERAL] Translations in Angular 6+ (Was Evergreen 3.3 Release Update)

Wed Mar 20 15:57:42 EDT 2019

Hi Dan

st 20. 3. 2019 v 17:11 odesílatel Daniel Wells <dbwells at gmail.com> napsal:

> Hello Eva,
>
> Thank you for raising this concern.  I think we are in the process of
> figuring things out as we go along.
>
> Our current best plan (I think) is to use the account we set up with
> POEditor.com.  It looks like you already have an account there, so at least
> you are familiar with what I am talking about.  What hasn't been figured
> out yet is what that overall update process looks like, and what the new
> build steps will be.  For the first part at least, your input will be very
> valuable.
>
> We did a test import back in November or so (I think it was at the
> Hack-a-way).  I would like to try to do another import to add any
> new/changed strings and see what happens, but being a completely new and
> unfamiliar tool, I am a little afraid of losing any work already put in
> there.
>
> So, a few questions:
>
> 1) Based on what you have already done in POEditor, do you think it is a
> viable solution?
>

I find POEditor to be quite suitable solution form translation. I discussed
the Issue with Ben last November - I have copied below my email to Ben with
my notes on POEditor.

>
> 2) I will do my best to preserve what is there, and I hope the re-import
> does the right thing, but how much would it take to redo the work done
> there so far if things go very badly?
>

I considered the translation strings only as a sample for testing the
POEditor interface and functions (and according to Ben there was also a
problem with extra newlines or white spaces before/after the string and
codes), so I don't mind too much if the current translation in POEditor are
lost.

>
> 3) Do you have a planned timeline for upgrading to 3.3?
>

If everything goes well, three of the Czech evergreen catalogs/consortia
are planning to upgrade to 3.3 during the July and August. Although now we
are a little uncertain due to the fact, that the web client interface of
the localized sandbox during Bug Squashing week looked almost not
localized, so we were not able to test some localization issues important
to us (hopefully the problem was just a sandbox and not a new version of
Evergreen)

Regards
Eva

> Sincerely,
> Dan
>
>
>

*---------- Forwarded message ---------From: Cerninakova Eva* <
cernin at jabok.cz>
Date: ne 11. 11. 2018 v 19:37
Subject: Re: POEditor.com for Evergreen Angular translations
To: Ben Shum <ben at evergreener.net>

*Hi Ben,To get feel of the POEditor interface I have gone through
translations  and briefly examined the features I normally use for
translations in the Launchpad. According to your previous note, I didn't
care much about the extra new lines and white spaces when translating.1.
Launchpad is quite cumbersome in many ways. POEditor interface on the
contrary seems to me to be kind of “lite” and  more "user-friendly". I
appreciate features like symbols marking white spaces, alerts when
translation exceeds a certain length of the string, ability to jump to next
translation using TAB key. I have never used tagging for translation before
but I think also the possibility off adding the tags might be useful. And
no timeout errors as it often happens in Launchpad ;-)2. Downloading or
exporting translation seems to be quite straightforward to me (much easier
than in Launchpad). However, I am used, that the English string is used as
the Message ID, while in files downloaded from POEditor in various formats
it is different (eg ngb.timepicker.increment-*

*seconds, or a number of the string like 889581076845216138 is used as a
message ID instead). Because I do not understand the Angular issue too
much, I just assume it's okay.3.. Currently I don’t see an opportunity to
copy the English string to translation field by one click (as it is
possible in Launchpad). Such a feature is widely used and is quite useful,
especially in cases when string contains white spaces, variables etc. Based
on what I have found, this function should be available in POEditor.
However, the right black menu bar in my POEditor account looks quite
differs from the screenshots in the POEditor Knowledge base and have much
less (and unmatched) options. If I understand the POEditor Knowledge base
well, contributors do not have access to the “Copy Terms to Translations”
feature unless they ask the project owner or an administrator to make this
function available.4. I also miss the suggestions based on previously
translated terms. Is the function “Translation memory suggestions”
available for Open source projects in POEditor? I consider this feature to
be one of the key functions helping to limit duplication and
inconsistencies.5. Is it planned to use both Launchpad and POEditor at the
same time or shall we use only one platform for all translation eventually?
And would strings be gathered all together in one project in i POEditor (it
seems to me they are). Or are they divided into templates, similarly to
Launchpad?  I am asking thees questions because  due to the consistency of
translations it is handy to have all translations searchable simultaneously
at one place (as I see it currently in POEeditor). From this point of view,
the Launchpad is not very suitable as the translation are separated in many
templates. The individual templates might be helpful sometimes to provide
context for translators at the first sight (e.g. translation of the „order“
might be different depending on whether it is used in the acquisition or
for hold management). However, to be consistent in terminology, it is
necessary to be able to search all strings simultaneously across all
templates. This is impossible in Launchpad (which is a great complication).
On the contrary, concerning this issue the POEditor seems promising to me.
And if individual templates would not be used in POEditor, could e.g.
tagging be used to help distinguish the context? (Though I am not sure at
the moment such thing would be necessary — I am just thinking aloud.)6.
This is more about the Evergreen  workflow not about the POEditor
interface:I would appreciate some introductory instruction from developers
for translators about the Angular strings (what do they look like, what
parts of the strings usually are not supposed to be translated, probably
later also how to add custom strings etc.)I also think it would be  always
useful to add as much context and comment as possible to particular string
for translators (not just in terms of Angular). It is sometimes really
tricky to understand the context of the string in cases when it could be
translated different ways (and have different meaning), when abbreviations
are used etc. Such situation happen to me quite commonly when I am
translating.I wonder if there is a way how to communicate with developers
over particulars string during translation process and make things clear
immediately. For example  using comments (just thinking aloud)?It is likely
that  I will find other things to point later, but if I summarize my
present findings:*

   - *I consider the missing “Translation memory suggestions” feature (see
   point 4) to be serious complication for translators.*

   - *I quite like the POEditor interface. Except missing “Translation
   memory suggestions” feature and assuming there is possibility to provide
   translators the "Copy term" function (see point 3) I find POEditor quite
   suitable for Evergreen translations.*

*Many thanks for your effort. Please, let me know if I can help some
more.Eva*

> On Mon, Feb 25, 2019 at 11:52 AM Cerninakova Eva <cernin at jabok.cz> wrote:
>
>> Hi Daniel,
>>
>> Considering the last year discussion about integrating Angular 6 template
>> translations into the Evergreen translation tools, I would like to ask a
>> question about translation workflow of Evergreen 3.3 release. Will it
>> change some way in comparison with previous releases, due the impossibility
>> to use Launchpad for translations of Angular strings? And if so, how the
>> Angular strings are supposed to be translated during the 3.3 release
>> process? (I am asking from translators point of view.)
>>
>> Thanks for the answer ;-)
>> Eva
>>
>>
>>
>>
>>
>>
>>
>> ---
>> Mgr. Eva Cerniňáková
>> cernin at jabok.cz
>> Tel. +420 211 222 409
>>
>> Knihovna Jabok
>> http:/knihovna.jabok.cz
>> Tel.  +420 211 222 410
>> Jabok - Vyšší odborná škola sociálně pedagogická a teologická
>> Salmovská 8, 120 00 Praha 2
>>
>>
>>
>> st 20. 2. 2019 v 16:03 odesílatel Daniel Wells <dbwells at gmail.com>
>> napsal:
>>
>>> Hello all,
>>>
>>> Two weeks have slid by once more, and today we mark, ostensibly, the
>>> feature freeze for Evergreen 3.3.  Any new features not committed by the
>>> end of the day will need to wait for the 3.4 release in the fall.  Once
>>> again, here are the feature branches under consideration:
>>>
>>>
>>> https://bugs.launchpad.net/evergreen/+bugs?&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=WISHLIST&assignee_option=none&field.milestone%3Alist=86802&search=Search&orderby=title&start=0
>>>
>>>
>>> As careful observers will note, we still have one week after today
>>> before the 3.3 beta.  However, this exists not as a time to continue adding
>>> features, but as a time to make corrections for obvious issues which crop
>>> up due to feature freeze activity.  The cutoff for new features has
>>> historically encouraged a mad dash of activity, and this scheduling gap
>>> exists not as an excuse to postpone such dashings, but to remedy the
>>> problems it brings.  So I gladly encourage those so inclined to dash as
>>> madly as ever, but understand that it ends tonight!
>>>
>>> Now, that said, if a branch is in an obvious state of active review and
>>> revision, yet doesn't make the cutoff, please let me know and we can
>>> probably work it in.  I intend to start doing internal building and testing
>>> starting tomorrow morning, and will not be terribly keen on straggling code
>>> walking in unannounced.  Thank you for your diligence and understanding.
>>>
>>> Sincerely,
>>> Dan
>>>
>>>
>>> On Wed, Feb 6, 2019 at 12:40 PM Daniel Wells <dbwells at gmail.com> wrote:
>>>
>>>> Dearest fellow Evergreeners,
>>>>
>>>> After several months of quiet contemplation and tireless toiling by
>>>> many members of the Evergreen community, it is past time for a brief
>>>> message from me, your minimalist 3.3 release manager.
>>>>
>>>> First, as we enter this final trimester of the release process, it
>>>> seems worth revisiting the originally proposed timeline:
>>>>
>>>> 2/20/19 - Feature freeze
>>>> 2/27/19 - Beta release
>>>> 3/20/19 - Release Candidate
>>>> 3/27/19 - Final release
>>>>
>>>> Accordingly, we are now exactly two weeks away from our intended
>>>> feature freeze date.  Please recall, however, that there is now a one week
>>>> buffer between feature cutoff and the actual beta release, so if we reach
>>>> the evening of 2/19, and a few extra days would make or break your feature,
>>>> please do not hesitate to speak up.
>>>>
>>>> I've spent a few hours over the last several days looking over
>>>> everything targeted at 3.3 in LaunchPad and trying to get a sense of where
>>>> we stand.  As of this moment, there are exactly 99 uncommitted tickets for
>>>> 3.3.  I initially thought, "surely some of these do not have pullrequests,"
>>>> and while that proved to be true for 8 or 9 entries, inspection showed them
>>>> all to be close enough to deserve their targets.  So, let's just say the
>>>> 3.3 release has great potential!
>>>>
>>>> Looking forward, and given the nearness of feature freeze, I want to
>>>> encourage everyone to focus their energy for the next two weeks on our
>>>> "Wishlist" tickets, as these are in the most present danger of being left
>>>> behind.  As of this writing, there are 25 unclaimed Wishlist tickets hoping
>>>> for inclusion in 3.3:
>>>>
>>>>
>>>> https://bugs.launchpad.net/evergreen/+bugs?&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=WISHLIST&assignee_option=none&field.milestone%3Alist=86802&search=Search&orderby=title&start=0
>>>>
>>>> While the other 74 bugs for 3.3 are certainly welcome at any time, we
>>>> will have exactly one month between feature freeze and RC to devote to the
>>>> likes of these.  It is worth noting, however, that a good number of those
>>>> 74 are officially "Undecided" in importance.  I did a pass through them all
>>>> to pull out any which seemed like feature requests, but if you feel I
>>>> missed something, please target accordingly.
>>>>
>>>> Finally, in looking over things already committed for 3.3, I am struck
>>>> by a fair number of branches which are not flashy new features, but which
>>>> nonetheless are necessary endeavors to keep Evergreen humming along.  I'd
>>>> like to end this email with a special salute to those among us giving their
>>>> time and attention to things like Ubuntu and PostgreSQL version changes,
>>>> making sure it is something most of us never need to think much about.
>>>> Thank you!  If you are not one who generally watches LaunchPad closely, it
>>>> may be worth a few moments to peruse some of the committed 3.3 tickets to
>>>> see these folks at work:
>>>> https://launchpad.net/evergreen/+milestone/3.3-beta1
>>>>
>>>> Sincerely,
>>>> Dan
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20190320/9f483f08/attachment-0001.html>