where can the status be set in the database so the "update available" notice goes away from the status report ??

I have tried manually doing it, the cron will not do it, and i finally removed and re-installed theentire language to force a complete check on Spanish and German for the FAQ project and it reports

""One translation file could not be imported. See the log for details.

import translations file: translations://faq-7.x-1.1.de.po (Missing or malformed header.) ""

for both languages

A manual update to replace strings seemed to work - since no one is really supporting the FAQ module for drupal 7 it seems . . . .

The header was missing the last translator - emal field and revision date was not filled in

"Last-Translator: NAME (EMAIL@ADDRESS)\n"
"PO-Revision-Date: 2017-1-30 01:08+0000\n"

This is a complete mandatory header below

# LANGUAGE translation of PROJECT
# Copyright (c) YEAR NAME
#
msgid ""
msgstr ""
"Project-Id-Version: PROJECT VERSION\n"
"POT-Creation-Date: 2013-10-24 11:16+0200\n"
"PO-Revision-Date: YYYY-mm-DD HH:MM+ZZZZ\n"
"Last-Translator: NAME (EMAIL@ADDRESS)\n"
"Language-Team: LANGUAGE (EMAIL@ADDRESS)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"

Where can I set this to complete in he database so the status report notice turns off ??

OR send a message to whomever to fix the files for faq es and de ??

Comments

bobburns created an issue. See original summary.

bobburns’s picture

bobburns CreditAttribution: bobburns commented
Issue summary: View changes
bobburns’s picture

bobburns CreditAttribution: bobburns commented
Issue summary: View changes
Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented
Category: Bug report » Support request
Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented

I can not reproduce this. Downloaded FAQ 7.x-1.1, enabled the module in a German translated site. The translation is downloaded and imported by Localization Update module.

This is how the header looks like here:

# German translation of Frequently Asked Questions (7.x-1.1)
# Copyright (c) 2015 by the German translation team
#
msgid ""
msgstr ""
"Project-Id-Version: Frequently Asked Questions (7.x-1.1)\n"
"POT-Creation-Date: 2015-09-11 07:09+0000\n"
"PO-Revision-Date: YYYY-mm-DD HH:MM+ZZZZ\n"
"Language-Team: German\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n!=1);\n"

I suggest you remove the file from your server and let Localization Update download it again.

bobburns’s picture

bobburns CreditAttribution: bobburns commented

Unable to import translations file: translations://faq-7.x-1.1.es.po (Missing or malformed header.)

It is the same even when i DELETE the language and then re-enable it

When I fix the header as above to include the name - email field and when modified - it imports

Where are the po files to delete from the server - this => https://www.drupal.org/node/2318969 seems to say they only exist as database entries

Are not - ALL THE HEADER fields required in the header ??

What you show as the header that worked for you is mal-formed according to => https://www.drupal.org/node/2127833

AND when I fix it to the mandatory fields it works

BUT - the question is and was where in the database can the status be set to turn OFF the update available message OR run a SQL query even instead to do so ??

bobburns’s picture

bobburns CreditAttribution: bobburns commented
Category: Support request » Bug report

If you cannot reproduce this - and somehow whatever system you are trying to reproduce it on accepts a malformed header - that even you show works with a malformed header - it is a BUG - not a support request.

I am just ALSO asking where to set the status as complete - because even when i manually perform the "update" - and the system confirms the import - it STILL does not set the update status to complete - which would also be a BUG

SO THE QUESTION REMAINS - WHERE TO SET STATUS in the database - as a work around for this BUG

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented
Category: Bug report » Support request

Imho this is clearly a support question "SO THE QUESTION REMAINS - WHERE TO SET STATUS in the database - as a work around for this BUG"

bobburns’s picture

bobburns CreditAttribution: bobburns commented

It is actually TWO bugs

How do you install a malformed header po file - and why after it is imported does the status report not clear

STILL neither have been answered

Since I really do not want to WAIT on the fix to be made - because it is CLEAR it is simply right now a malformed header i have no way of fixing on the download server - IT IS NOT a support request - it is a "HOW TO WORKAROUND REQUEST" - while you or whomever would presumably look at WHY a malformed header worked for you and as it should NOT HAVE - for me

I realize a BUG REPORT is more serious than a support request - but I have no reason to believe the malformed header actually worked for you - even this asks for a workaround to a BUG

For you to focus on the last question I asked a NOT SEE the BUG is quite alarming

so here is the question ALSO to answer 'how did a malformed header work for you that is clearly malformed"?

bobburns’s picture

bobburns CreditAttribution: bobburns commented
Category: Support request » Bug report

This defines what is a BUG => https://www.drupal.org/core/issue-priority

It is TWO BUGS bY Drupal standards as of January 29, 2017

Bug (#)
Bugs that have significant repercussions but do not render the whole system unusable (or have a known workaround) are marked major.

Major bugs include those that:

Interfere with normal site visitors' use of the site (for example, content in the wrong language, or validation errors for regular form submissions), even if there is a workaround.
Trigger a PHP error through the user interface, but only under rare circumstances or affecting only a small percentage of all users, even if there is a workaround.
Render one feature unusable with no workaround.
Block contributed projects with no workaround.
Cause a significant admin- or developer-facing bug with no workaround.
Cause user input to be lost, but do not delete or corrupt existing data.
Cause test failures in environments not supported by the automated testing platform.

It causes all five of the last five issues

It causes the status report to not work, the update does not take even when the header is fixed and then works

Your "ho" aka "humble opinion" is wrong by Drupal standards

I should also point out that I do not know if the interface update works even though the import is successful AFTER I fixed the header

Seriously you need to inspect the software for this update bug - AND tell those two teams - wherever they are - to properly fix the headers - and then I can try to update it fully again - and if it works and clear the status report - then you know there is a BUG or the BUG is in the manual import as to the status report

i ASKED for a "workaround" on how to set the status in the database - you have also not answered

The last thing that should be going on is playing ping pong with the classification of the issue.

It is a BUG - Drupal standards define it that way

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented

@bobburns, have you considered that module support is all voluntary work and that shouting _really_ does not work. You will probably understand that by now I have very little motivation to help you on this issue.

bobburns’s picture

bobburns CreditAttribution: bobburns commented

Yes - I have - because each there is a problem with L10n update - you do not have a clue, and instead of simply answering a simple question - you have always deflected to something irrelevant.

I find it hard to believe your claimed re-production update with malformed headers actually worked and it appears more likely you just wrote that as a response

I never expected you to help or have an answer - that is why I only asked for a workaround to manually set the status in the database

I really was not asking for your help - only reporting the bug - and seeking a workaround to the second bug that even when the import worked - it still did not clear in the status report

The way the software works is not elegant and you avoid clear issues that are a problem

I discovered it is PHP memory hungry and has long run times that need to be set higher in the php.ini or the script will fail

I looked at how it loops over and over to accomplish the result

There is another issue like this with a patch I will need to re-find

This is not about helping me - this is about the software working properly - and the fact that you say you do not care is the real truth here

You illustrate Drupal's problem - angry programmers and module maintainers trapped by pride and shame under community peer pressures without pay

I hear you - but at the same time - the modules I have made and the improvements and fixes I have done I do not publish for free for this very reason you cast out there

There are a lot of modules in Drupal that do not work right and programming skills and talent vary widely - and a really good programmer would know exactly why this is happening and it would be a no sweat fix - but not here with you . . . .

The better position would have been to offer to look into it for compensation as a custom fix - you do not know I might have agreed to pay. I do not see anything in Drupal that commands free module posting or consulting support

In this case however - I do not think you really know what is causing it - so you make excuses instead

It is just sad you are proud of an obstructionist attitude that you have and that is what this post volley would tell anyone who comes across for years to come

Sutharsan’s picture

Sutharsan CreditAttribution: Sutharsan commented
Status: Active » Closed (won't fix)