I've made these changes & put them on staging. @CDenes_WMF - was the ommission of the : in the slovak version an error or by design

@Dwisehaupt @Jgreen @Ejegg just flaggin that the desired scope of this is likely to have some impact on disk size (but hopefully not on performance )

OK - the error is in the code intended to prevent utf8mb4 queries on dbs that don't support uf8mb4 - fixes coming through

Also - I replaced the above since I couldn't rebase - and then found I can't abandon it either now it is replaced

@thcipriani is there an extra permission required to be able to rebase https://gerrit.wikimedia.org/r/c/releng/dev-images/+/664919 - if I rebase locally git rejects it too

@hashar - it even has big bold headers :-)

This should work now - @KHaggard are you able to confirm?

@hashar - thank you for the great write up

@Ejegg @jgleeson can you take a look at the above where @hashar has spelt out how we could do this.

On the buildkit issue I synced our repo today - there was one patch we hadn't upstreamed & a bit of mess but I fixed that up and then did a commit like

I tried a few things on the gerrit front just now & I got us to the point where our code is exactly the same as upstream but we still can't maintain it in a sensible way

Yep - that worked!

oh - good thinking! it could be!

I *think* the reason is that one of the headers is missing and is being rendered as an empty line as per below

It seems that the placement of this part of the headers

Just noting that the issue with the non-french subject is resolved - the issue with some clients not handling the headers we have not yet resolved

@MDemosWMF it looks like we already deployed this - can you confirm it's all good?

The above patch is in review - I also put up a PR against master to fix the weird formatting on the filter tab - https://github.com/civicrm/civicrm-core/pull/20784 - but I think we can be relaxed about what happens on that one getting merged. The filter formatting is not a huge issue

@EYener this should be correct now - we just need to merge https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/703492 & then we can close it

@MDemosWMF I've spun off that latest request to https://phabricator.wikimedia.org/T286520

@EYener that is a generated file - but in terms of communicating the extra fields you want it might be a good way to do it - since I'm sure that you want to speak sql to me

@EYener - there are a few steps involved - we have to load the triggers, create the fields, add to accoustic upload etc - so I won't be able to just +2 & deploy. But it definitely is a good time to propose additional fields if there are some you want & if that is easier to show us as a patch then go for it

I have worked with Coleman to get a version of the patch I worked on (actually not really a version - something completely different he wrote :-) - and hence the upstreaming part is sorted.

@EYener I just made the same update to that search that I did on live - see

This is now done - the data is in & the jobs are off

I tried to run this today but hit an issue

drush @wmff cvapi TargetSmart.import_job csv=/path-to-civi/files/targetsmart/targetsmart_export_june_2021_1_first10_rev.csv batch_size=1 mapping_name=2021-targetsmart  add_to_group_name=818 identifier=1 
Row failed to import Invalid value for field(s) : field ID; ; field  [error]
ID; ; field ID; ; field ID; ; field ID; ; field ID; field ID; field
ID; Array
(
    [0] => Invalid value for field(s) : field ID; ; field ID; ; field
ID; ; field ID; ; field ID; ; field ID; field ID; field ID;

(back in doing for the upstreaming I need to do - ref https://github.com/civicrm/civicrm-core/pull/20707

@EYener I deployed a change to staging and to live that addressed the issue you identified. I need to do some more work on upstreaming but for now it should be working

@CDenes_WMF sure - this isn't actually in the sprint at the moment - @DStrine can let you know on that side of things

Ok we don't use supplemental_address_3 so that part is fine. For some reason we filled up the data with 'NA' for supplemental_address_1 - that seems to be our doing & I guess we can strip it out of the csvs

@LeanneS - I just imported the first 9 rows using import

I've split off the first 10 & am trying a UI import for them to check out the mappings - the UI selection looks like - note the word 'tab' is written in for the separator, contains headers is checked & it is set to update

yay

this should be working now @LeanneS

@MDemosWMF we should be picking up more of these correctly now

The above patch went out in today's deploys

@Dwisehaupt tried this switch over just now but we hit a snaffu - there are some places in the code that try to translate the CiviCRM dsn to use in drupal queries. This is old legacy cruft which we would ideally remove like this https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/701224

thanks for confirming!

I'm turning off the job now - this url shows the remaining contacts who have harrison-like first names - their preferred language is not 'Japanese' - although in some cases it is weird variants - these could be fixed by bulk actions in the UI & we forgot to look at how in our DR meeting this am (@MBeat33 @SHust - we should maybe still look at that)

@CDenes_WMF actually DO create a new phab - because some of the languages - eg. Russian - appear to be new

Actually I think I misread - I think the short answer is yes since there are a bunch more translations there

Ok - I overdid the sorting last time.... https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/civicrm/+/701014

@MDemosWMF I just deployed #3 - 'support for Fee Amount'