Hi Dan
st 20. 3. 2019 v 17:11 odesílatel Daniel Wells <dbwe...@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* < cer...@jabok.cz> Date: ne 11. 11. 2018 v 19:37 Subject: Re: POEditor.com for Evergreen Angular translations To: Ben Shum <b...@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 <cer...@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á >> cer...@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 <dbwe...@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 <dbwe...@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 >>>> >>>
