Here are the german files for YaBB 2.7, adapted to build 2066. Errors in the expression reserved. These will be fixed after a test in the next few days, if necessary.
The package includes formal and informal.

good, it is not necessary. Then I do only the one correction in the Admin.lng and Profil.lng. There was nothing else to do.

But so long as the files have been saved as UTF-8, then converting German alphabetical characters to html characters isn't necessary.

2.7 uses UTF-8 exclusively so converting characters to html code should not be necessary and may actually break some things.

I revised the German files again. Where possible, I converted the German umlauts (ä, ö, ü, ß) into html-code. Only in the Profile.lng was not 100% possible. I hope there was no mistake. The previous tests were good.

These are the most current zips of the German Language files and match what is in the SVN

It's even possible that the error is related to a previous bug fix on your install that isn't quite right. 

I'm hoping by the end of the week I'll have an updates in the SVN and the Strict2.7.0 test section here updated.

Okay, I will finish the help files as soon as possible. I will need one more week, though. I will then upload four orders under the language files to my test server. German_formal and German_informal are the ones modified by me. The others I leave in original. You can then test yourself what is good and what is not. We'll take it later, we can decide later. But as already written, the error is there, too, if I have only the English language on the server. So it can not necessarily be due to the German files.

What appears to be happening: something being opened and processed by DetailedVersion is reporting that the function 'automaintenance' is in more than one place. But we know that that can't be true because when the name of that function was changed in just one place (Subs.pm), DetailedVersion reported that the renamed function was in more than one place.

I know that Subs.pm hasn't been accidentally duplicated because I tried to reproduce the error we're seeing and having two versions of Subs.pm had similar but not identical symptoms AND turning off the redefine warnings in Subs.pm stopped the errors that did happen.

Having the redefine warning turned off is not a big issue - a number of AdminCenter items have it turned off due to a repeated function name that cannot be changed.

So - I suggest ignoring the problems in DetailedVersion while you work on the Help files. (DetailedVersion should still be able to report serious errors with the Language and Help files.)

Once you have them working, I can test the finished files on my test server. Maybe the problem will show up for me then.

I just do not understand. For me, only the German language files modified by me only work correctly. If I make the old ones on the server, I get no error message, but in the detailed version display then unknown version processing is displayed. I hang a screener. Everywhere where the build is, the German files have been modified by me and work well, which, however, have nothing to do with the current error message. I have all the files, including the English.

I have no plan how to handle this error message without using redefine. Is possible, but then in the detailed version display as good as nothing is displayed. I'm just wondering, what's the problem? If it's not up to Perl, why?

Edited:

I'm simply not getting the errors on my test server. I have not yet uploaded German_Formal and German_Informal here due to the Mods.

If your Language and Help files work fine for everything thing except for DetailedVersion, then let's not worry about it for a while - we just need to make a mental note to come back to it. (I didn't test anything that actually called for automaintenance when checking things on your test install.)
Edited:

Dandello wrote on Oct 30^th, 2017 at 6:11pm:

That's why I've highlighted this error message

next:

nothing, the same error

next:

I still have a problem with the old and new German modified files, but this does not trigger an error message. I do not know exactly how to describe it in English.
I will probably soon have 4 German languages on the server. The old German files just do not work properly. The modified by me already.
I'm doing a lot of work with it. I'll describe it somehow, I just do not know how.

I actually wanted to know if the error is also triggered on your server.
Otherwise, I ask today a friend or my nephew, who also have their own server with other providers.

Not exactly the same error message - this one has the new sub name which isn't called from anyplace within YaBB and isn't likely to be referenced in any Perl Module.

In DetailedVersion.pm comment out or remove 'use warnings;' and see what that does.

Has no effect, same error message.

Quote:

Okay - while I can reproduce part of the issue you're describing, I can't reproduce all of it. A quick check for if it's coming from the outside: In Sources/Subs.pm find 'sub automaintenance' and change it to 'sub yabbautomaintenance'

Note: this change will temporarily break the YaBB install's ability to use the automaintenance function. But this is just for testing.

I have now done some tests, no one has succeeded, which is not so tragic. I thought later that it can not come alone from the German files and was right. I have deleted all German files from the server, the settings.pm adapted accordingly and they there, the error message comes also in the English language, even if it is standalone.

Quote:


So it can not lie with the German files.

With

no warnings qw(redefine); 

you can suppress the error message, but then I do not get much in the detailed version displayed, which is also not so important.

In principle I can with both lives because these information is not really important.

Now would have to know if this error message with you does not appear, which Perl modules (I think it is a Perl problem) with you are installed.
I have a usable script for this .. (appendix) (chmod 755)
Maybe (only if the error does not occur) I can update with appropriate module update the error and we then know what it is.

I would like to make some tests, I need only a few help files. I'm just translating. Is just a little bit much. I then document everything. Further error messages in the test form have not been displayed so far.

no warnings qw(redefine); 

This works, however, there are problems with the old German files. With the modified by me it works, However, in the detailed version display only very little is displayed. With the old German files nothing is displayed and there is an error message. I'm going to document it all, and then we'll see what we're doing. Patience brings roses, so they say in Bavaria.

The 'nothing showing' almost always means one or more duplicated files with a different names (or in different folders) but with the same version variable. (Like two copies of Subs.pm with one named Subs.pm and the other named xSubs.pm or one in Sources and the other in Admin.) Considering the error that shows when the redefine warning is on - check for duplicates of both Subs.pm and AdminSubs.pm

no warnings qw(redefine); 

This suppresses the error message, but under "Detailed version" almost nothing is displayed, at any rate unbreakable.

$german_formaladdmoderatorslngver
$german_informaladdmoderatorslngver

This is how it works, with the small error message from the server.

We will not be able to bypass this message, except I make only a German file on the server, which was then not modified. But that is not the point. Both must work and be installed in a forum. Everything else would be a step back.

It would be enough, if only the error message would be hidden, because it works so.

I've been through all the possibilities now, this is the best solution.
Feel free to always experiment on my test server. You can not destroy anything there.

Edited:

Dandello wrote on Oct 27^th, 2017 at 10:47pm:



Removing from answer # 43 +45 "no warnings qw (redefine);" again.

If you do not remove it, it does not work.

It does not work with the OLD German files. There is then displayed in the detailed version nothing. An error message is displayed.

Quote:


With the modified files of me it runs, but still a failure message.

Quote:


and this points back to the maintenance mode.

So I gather you mean that everything's working with DetailedVersion without having the redefine warning turned off?

I told you we can do it today.

Removing from answer # 43 +45 "no warnings qw (redefine);" again.

At the moment I still have the German files modified before me on the server and the work. The old I will still test.

No error message in the error log.

One place to fix: In DetailedVersion.pm find

                            $txtrevision =~ s/[.]help/helpver/igxsm;
                             ${$txtrevision} =~
                               s/\$Revision: (.*?) \$/Build $1/igxsm; 

and replace with

                            $txtrevision =~ s/[.]help/helpver/igxsm;
                             if ( ${$txtrevision} ) {
                                 ${$txtrevision} =~
                                   s/\$Revision: (.*?) \$/Build $1/igxsm;
                             }
                             else { ${$txtrevision} = q{}; } 

That will take care of the missing revision variable error.

I did that a long time ago ..

%load_txt = (
 '616a' => q~Denken Sie daran, dieses Forum ist im <a href="{yabb adminurl}?action=newsettings;page=maintenance" style="font-weight: bold;">'Wartungsmodus'</a>.~,
 '617' => q~Denken Sie daran, letzte Sicherung wurde durchgeführt am:~,
 );
  

That maybe the errors can come from the help files, I thought so.
I'll work it out as soon as possible.

pyragony54 wrote on Oct 27^th, 2017 at 5:51pm:


Yeah - first in your OLD versions, add to Admin.lng

%load_txt = (
 '616a' => q~Remember, this forum is in <a href="{yabb adminurl}?action=newsettings;page=maintenance" style="font-weight: bold;">'Maintenance Mode'</a>.~,
 '617' => q~Remember, last Backup was done on:~,
 );  

That should fix the problem with the old versions.

Then we can sort out the new versions - that

Use of uninitialized value in substitution (s///) at /var/www/vhosts/yabbtest.de/cgi-bin/yabb2/Admin/DetailedVersion.pm line 469. 

error is referring to a poblem in a help file.

I have uploaded the last two versions of the german files. In the detailed version check is then nothing, in the error log is:

Quote:


okay, I'll do the fixes in the Subs.pm and AdminSubs.pm

nothing is to be seen in the detailed version display, same error message.

I have then uploaded the modified German files again. The detailed version display is displayed again. However German_Informal is not displayed now.

Quote:


I have modified Subs.pm and AdminSubs.pm.

Looks like we're close to the result.

Do the same to Admin/AdminSubs.pm or put back the last versions of German_Formal and German_Informal that worked. (We know that the problem began when those files got replaced with the newest versions.)

not work

Quote:

I knew exactly where the duplicated sub routines were when moving from 2.5 to 2.6. But there is no duplicate of Automaintenence. However, until the problem shows up for me so I can hunt it down, the quick fix is:

In Subs.pm, just after the

no warnings qw(uninitialized once); 

add

no warnings qw(redefine); 

The real puzzler is: This didn't show up for you until you loaded the edited German_Formal and German_Informal packs and it doesn't show up for me when those same packs are loaded. 

Dandello wrote on Oct 25^th, 2017 at 1:55pm:



The problem was before already and was probably bypassed here.
There will probably be no other solution.

http://yabb26.yabbforumsoftware.com/261_diffs/Sources/subs.htm

nginx can not process perl scripts directly in the default configuration. Bloody hell. Only as a upstream proxy does it. You can change it with a script, but that takes a lot of experience. I can do it, but what do those who can not. So Apache remains the first choice for YaBB.

https://www.howtoforge.com/serving-cgi-scripts-with-nginx-on-debian-squeeze-ubun...

Dandello wrote on Oct 26^th, 2017 at 3:54am:



Okay, no problem. I just make simple German_formal and German_informal. Otherwise, I will not change anything. I have another idea. My server has Apache and nginx. I can switch. I'll try something. If then the error message no longer appears, then we know more. I just try it. Experience makes wise.

I didn't find anything that would explain the problem in your test site. I did find a few files (like YaBMod.lng) that had a couple characters that had obviously been converted badly. Found the same word in an older file and fixed it.

The Help files should be next on the list as I'm still working on the Mods. (Although the language sections should not be changing on those.)

Okay, after you have my modified German files loaded into the SVN, so I can assume that they are in order. What is more important now? The mods or the help files.

Let me check the files once again and then I think we're probably okay to upload the German files to the SVN.

It's possible this problem is like one I had here with the Russian Language Pack - on this server the Russian folder is named Russianx because (for no apparent reason at all) Russian/Debug.lng would load when the chosen language was English. This could not be reproduced on my test server. Did not happen in 2.6. It only happened with 2.7 after Perl was upgraded.   

Before Friday I can not do this now Great. I unfortunately have to get up at 4:00 am in the morning and that is in 7 hours. Thursday I still work until the late noon. I will first times a new Installatio to make the test server without German files and then see what the error message speaks.

For me, one thing is certain, both German languages work.

Would be good if you can play all the corrections of the last days in de SVN, I do not know now in how far I have all this secured,

Okay, this one has me stumped as I cannot reproduce the error on the clean install of the most current build in the SVN.

What that error is saying is somewhere in the files in the Admin folder or in a file in the Sources folder is a function 'sub automaintenance' that is not in Subs.pm. (Or it's duplicated in Subs.pm.)

That's what the error says is happening.

Now we can turn off the warning. But that warning is an indication of something very odd happening.

So - here's what I would be doing if I could reproduce the error.

1) do a phrase search over all files in Admin, Sources, and Languages for the phrase 'sub automaintenance'. (I can do this as my test server is on my desktop machine). If only the one instance is found ->
2) Replace the new Language packs with older versions and see if the error still pops up. If that stops the error, start replacing the older files with newer ones until the error shows up again.

I am guessing that since this happened recently and you haven't added any Mods, the problem is, in fact, in one of the new language files.

I'll run a comparision between the old and new versions of the files and see if anything jumps out at me. But later.

I do check the error logs on your test site.

Dandello wrote on Oct 25^th, 2017 at 1:55pm:



Are attached in my last answer (# 31).   

But first drink a coffee. Good Morning.
With us, the sun goes down.

Edited:


Dandello wrote on Oct 25^th, 2017 at 1:55pm:


All right. I have not found this error description in the English language files. So I wondered where this came from.

That'a not a YaBB error - that's a Perl error being echoed as a YaBB error. (And Perl/server errors are in English.)

Translation - I'm going to have to do some digging to find the error.

Edited:

See, it works. I just changed the German files in the header (see it to you the new files).



However, the following error appears in the error log, which is related to the maintenance mode (after calling the version check)
What the hell does the maintenance mode have to do with it?
In addition, you can not see any tabs in the table.

Quote:


and

Should not that be in German? Am I still somewhere error?

cool I also find the displayed date (time).

Error or minor injury. (Works for both.)

Dandello wrote on Oct 24^th, 2017 at 6:40pm:


????

Have I mentioned that Detailed Version check does a pretty good job of trapping serious boo-boos? 

Dandello wrote on Oct 24^th, 2017 at 6:16pm:



Uppps

Edited:

When the Detailed Version check has issues, the error almost invariably shows up in the error log.  :

In this case in Germal_Formal/Backup.lng

'47' => q~Sind Sie sicher, dass Sie löschen wollen~?, 

  should be

'47' => q~Sind Sie sicher, dass Sie löschen wollen?~, 

Having the proper folder related variables for the version will avoid things like 'No revision data Changed on Tue Oct 24 06:42:25 2017'

Okay, if I have set in German, then the version check shows me nothing. Whether formal or informal. Just a blank page. If I switch to English, then the version check shows only formal. I installed both German languages and everything worked without problems. I can switch as I want, no errors. Log in to yabbtest and see.


http://yabbtest.de/cgi-bin/yabb2/YaBB.pl


It may perhaps still make a difference now, but in Germania one is proud of the two languages, especially in the older generation to maintain the proper distance. If it is not otherwise, then maybe or otherwise.

$german_formaladdmoderatorslngver = 'YaBB 2.7.00 $Revision: 1848 $';
 @german_formaladdmoderatorslngmods = ();
 if(@german_formaladdmoderatorslngmods) {
     $german_formaladdmoderatorslngmods = 1; 

$german_informaladdmoderatorslngver = 'YaBB 2.7.00 $Revision: 1848 $';
 @german_informaladdmoderatorslngmods = ();
 if(@german_informaladdmoderatorslngmods) {
     $german_informaladdmoderatorslngmods = 1; 

or
germanformal
germaninformal


I can test this and am almost certain that it works as well. I like to do the work.
Edited:

But the Detailed Version Check (in the Admin Center) will give the wrong information for the German packs and may not properly load at all.

I do not quite understand that now. I have both versions of german on my test server and no problems. Works flawlessly.

mySQL does fine with UTF-8 (I know this for a fact.)

According to NotePad++ the the two files you mentioned are already in UTF-8, and what's supposed to be in the file is the 'screen name' for the language. These are the files YaBB now reads to get the data for the language names hash.

And do we need to tell people they can't have both versions on their forum because it will completely break the detailed version checker? 

$germanaddmoderatorslngver = 'YaBB 2.7.00 $Revision: 1848 $';
 @germanaddmoderatorslngmods = ();
 if(@germanaddmoderatorslngmods) {
     $germanaddmoderatorslngmods = 1;
 } 

The highlighed sections should be the folder names (in lowercase) so every single *.lng file has a unique version variable linked to it's name and folder.

Attached both German files. I have tested them, they are error-free so far.
Please delete all other German files, they still had errors.
Next step will be that I will convert these special characters (ä, ö.ü.ß) into ANSI. This still has time and is not relevant for the current version (but could possibly make problems with an SQL database).
The two files "German_Formal.txt" and "German_Informal.txt" must not be encoded according to UTF8.

Edited:

With any luck, I'll have it in the SVN later today or tomorrow. Thanks for all your hard work on this. 

German Files for Build 1926 (Formal)

Boards, Members, Messages and Variables I have not consciously translated, because they are so synonymous on the server. This could lead to misunderstandings and I think every YaBB user knows so well.

I do not know it either. Am almost finished with the translation of the Convert.lng. This is faster than I thought. I think I did it until Monday.

It took me more than a day to make it - I'm still not sure what language the conv1x section was in originally, but it wasn't English. :
At least there are a lot of shared phrases.

I'm taking a few days away then back to working on Setup.pl

The translation of the Convert.lng I do not create in one day. This takes a few days.

The German and German_Informal Language packs are in the SVN. The zip is no longer in tha SVN so you need to get the 'snapshot'.

Now to check the other language packs and reorganize them as well.

And there was also Commander Data, who with his 2-bit rake brain can easily solve any simple addition within 2 hours.

Not a problem - it's been ages and ages since anyone has really touched the language files. I swear the Language in Setup.pl was translated into English via Chinese, Russian, German, and possibly Klingon. 

There I wait until it is in the SVN. I'm just making the help files.
This is a lot of work. In the general language, that is to say, no one directly approach is as good as not possible. So, double work.

pyragony54 wrote on Sep 14^th, 2017 at 6:33am:


UTF-8 doesn't require turning any characters into HTML entities or ASCII. So don't worry about that. I can convert the ISO files to UTF-8.

Also this is new in Admin.lng:

%setup = (
 '7' => q~Setup and Converter Back-up files~,
 '7a' => q~Language Encoding Converter Back-up files~,
 '8' => q~When you have tested your forum and made sure everything has been converted correctly, you can remove the Setup Utility and your old YaBB back-up files in the Converter folders (if any exist).  This will also delete the conversion programs so they cannot be run again. <strong>Note</strong>: This does not remove files in the ConvertLang folders.~,
 '8a' => q~When you have confirmed that the Language encoding has converted correctly, you can the delete the ConvertLang folders.~,
 '9' => q~Delete old Back-up files, setup, and conversion utilities~,
 '9a' => q~Delete Language Conversion Back-up files~,
 '10' => q~Old Back-up files deleted~,
 '10a' => q~Language Conversion Back-up files deleted~,
 'conv' => q~To convert 1x or 2x files to 2.7.00~,
 'conv2' => qq~<strong><a href="$boardurl/Setup.pl">Go to Setup/Convert</a></strong>~,
 ); 

Finished and tested. No more error messages in the language files.
Also no error messages within the forum. Everything looks good.
Now only the mod has yet to be made. This is your part. I'm not going to get it.
Both should be installable, shared and standalone.

Later I will convert some special characters and umlauts into ASCII, as far as it is feasible (because of Java script). Then the German files UFT-8 can be.
With the help files, I do the same.

Edited:

I get it there, just with Notepad ++ no chance

When I looked at them, some of the files were in ANSI (ISO), some were in UTF-8 and a few were in a variant of UTF-8. 

The trick with Notepad++ is to 1) make sure you have a backup copy of the file in case you mess up the conversion and 2) use 'convert'. 'encode' lets you look at the encoding but doesn't save it that way. (It's a good way to figure out what the encoding is when you don't know.)
Edited:

I have now myself Notepad ++ loaded. I do not understand that. The files should be in ISO. I had no German files in UTF-8. If it does not work, then I must use ASCI. Funny is, the German Formal we normally indicated.

I have no problem replacing the special characters with ASCI. Only Java has a problem.

Well, since YaBB 2.7 doesn't use ISO, it's a good thing they're in UTF-8 

So you don't think I'm slacking off - today is 'Fix the Convert1x converter' day. 

I have never had to deal with it. I have googgle asked, but from Notepad ++ I have since nothing found. The German files are finished as promised, I just need the conversion. I do not understand why the German_informal is not ISO. Before they were ISO. I have no idea.

I can do the encoding. NotePad++ does a good job with that.

I have the German_informal comedically in UTF-8 (anyway some files) I do not know how I get the ISO. Have never had to make and have no idea how that goes.

Updated German Language Pack in first post.

Language Pack zip now in SVN as well.

This is the most recent one I have. Some items have been moved. The items for YabMod are now in their own file (again), and the new items for ManageTemplates have been moved out of Admin.lng to Templates.lng.

This pack goes with SVN build 1818+

Edited: