Updated German Language Pack in first post.

Language Pack zip now in SVN as well.

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

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 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 get it there, just with Notepad ++ no chance

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>~,
 ); 

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. 

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.

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

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.

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:

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

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:

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



Uppps

Edited:

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


????

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).

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.

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.

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.   

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.)

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...

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. 

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.)

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.

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.

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

$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:

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

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.

Has no effect, same error message.

Quote:

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.

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:

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.

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

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

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.