[Gelöst]Powershell, Import-NAVApplicationObjectLanguage Err.

Guten Tag zusammen,

als Best Practice hat es sich herausgestellt die Sprachen vor einem Merge aus den Textdateien zu extrahieren und diese im Anschluss nach dem Merge wieder zu hinterlegen.

Nun habe ich das Problem dass mir der Import Befehl manchmal eine Fehlermeldung ausgibt:

WARNUNG: UnhandledErrorMessage
Import-NAVApplicationObjectLanguage : Die Sequenz enthält mehrere übereinstimmende Elemente.
In Zeile:1 Zeichen:1

Vorgehensweise:
1. Export der Sprache eines kompletten Textdateien Sets
2. Merge (Orig: NAV 2015, Mod: Partnermodul A, Target: NAV2015 inkl. Partnermodul B, Result: NAV2015 Partn. A + B)
3. Integration der Sprachen mit dem Import-Befehl(Evtl. aus verschiedenen Modulen, ohne zuvor einen Join durchgeführt zu haben)
(Ein Join der Sprachen unterschiedlicher Module verursacht eher noch mehr Probleme da die Elemente dann wieder mehrfach auftreten)

Frage:
- Wie kann ich die Sprache nachträglich via Powershell einfügen bzw. die Fehlermeldung umgehen?
- Wie kann ich doppelte Elemente entfernen?
- Muss die Sprache zwangsweise über den Textimport in NAV selbst durchgeführt werden (hier erscheint keine Fehlermeldung, dazu muss dann aber immer Datum + Zeit gesichert werden... außerdem lässt sich der Prozess nicht automatisieren und unkompilierte Objekte bereiten Probleme, genauso wie MenuSuites wenn ich mich recht entsinne)

Leider stellt die Finsql keinen Befehl zum automatischen importieren der Sprache zur Verfügung:
https://msdn.microsoft.com/library/hh165406.aspx

Wie habt ihr das Problem gelöst?

Über eure Ideen/Feedback würde ich mich freuen.

Viele Grüße

Zuletzt geändert von Ricster am 16. Oktober 2015 13:23, insgesamt 1-mal geändert.

Ich hatte die Fehlermeldung bislang noch nicht.
Aber ich habe aus anderen Gründen ein Skript erstellt, um die Translationsdateien zu bereinigen, um nur noch die relevanten Captions übrigzulassen, das liegt hier.
Wenn die die Fehlermeldung damit nicht mehr kommt, sollte es reichen, nach dem Merge erst die Standardcaptions zu importieren und danach die damit erzeugten Add-on-Captions hinterherzuschieben.

Außerdem die Modeltools des aktuellen Cumulative Updates für Import-Module verwenden.

ModelTools3.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Leider stellt die Finsql keinen Befehl zum automatischen importieren der Sprache zur Verfügung:
https://msdn.microsoft.com/library/hh165406.aspx

Wenn es nur um Versionen ab NAV 2015 geht, dann schon. Die Liste in deinem Link ist für NAV 2013.
ImportTranslate steht ab dieser Version zur Verfügung. Alternativ auch ImportLangModule für die flm-Datei, bei letzterem Befehl bleiben dann auch Datum und Zeit am Objekt erhalten. Ein laufender Dienst für die Datenbank ist aber dann bei beiden Verfahren erforderlich.

Ab NAV 2015 ist die Liste unterstützer Befehle ja auch sonst etwas länger geworden.

ImportTranslate steht ab dieser Version zur Verfügung.

Auf die undichte Stelle bei Sprachimporten in veränderte Codeumgebungen kann man natürlich auch da stoßen. Das ist ein Grund mehr, weshalb ich lieber bereinigte Sprachdateien verwende, denn darin sind die Kommentarzeilen, die den Quellcode ruinieren können, natürlich nicht mehr vorhanden.

Vielen Dank für deine Antworten Kowa,
ich werde dein Script anpassen und die Captions extrahieren, leider aber erst nächste Woche.

Dann gibt's nochmal eine Rückmeldung

(Außerdem werde ich mich auf die Suche nach dem Verursacher machen, da ich noch nicht genau weiß, welche Übersetzung den Fehler verursacht.)

(Außerdem werde ich mich auf die Suche nach dem Verursacher machen, da ich noch nicht genau weiß, welche Übersetzung den Fehler verursacht.)

Wenn man in einer Skriptvariante diese Zeile

Code:

[bool]$IsCaption = ($lineStart.IndexOf("-A") -gt 0)

durch einen bestimmten Sprachcode ersetzt, hier z.B. für Französisch (FRA)

Code:

[bool]$IsCaption = ($lineStart.IndexOf("-A1036-") -gt 0)

dann kommen nur die Zeilen für diese Sprache in die extrahierte Datei.
So kann man dann nach und nach eine Datei pro Sprache erzeugen und die Fehlerstelle schneller einkreisen.

Hat nun etwas gedauert.
Der Verursacher des Fehlers war die Page 9020, hier hat mir der AutoMerge-Command zweimal den ActionContainer "ActionItems" eingefügt, d.h. das Objekt war auch nicht kompilierbar.
Grundsätzlich hätte ich die Objekte auch zuerst importieren können, die Fehler beheben, wiederum exportieren, die Sprache integrieren und importieren können, dann hätte es keine Probleme gegeben .

Hab mir folgende kleine Funktion gebaut,
um die Sprachen pro Objekt einzufügen und dabei eine Log-Datei zu generieren sollte der Import fehl schlagen.

@Kowa:
Hast du zufällig eine Funktion um die Sprache von bspw. DEU auf DEA/DES zu ändern via Powershell .
Ansonsten würde ich die Funktion "ExportAddonFromTextFileLanguage" noch entsprechend anpassen damit die Zielsprache angegeben werden kann.

(Der Code ist Rookie Style, aber tut seinen Dienst)

Code:

function Import-NAVApplicationLanguageFiles
{
    [CmdletBinding()]
    Param(
        [String]$Source,
        [String]$Destination,
        [String]$LanguageFiles,
        [String]$LogFolder,
        [bool]$TransferObjects
    )
    $TextFiles = Get-ChildItem -Path "$LanguageFiles"
    $i = 0

    $StartTime = Get-Date

    foreach ($TextFile in $TextFiles)
    {
        $NowTime = Get-Date
        $TimeSpan = New-TimeSpan $StartTime $NowTime
        #$Command = $importfinsqlcommand + $TextFile
        $LogFile = "$LogFolder\$($TextFile.Basename).log"
        $i = $i+1
        $percent = $i / $TextFiles.Count
        $remtime = $TimeSpan.TotalSeconds / $percent * (1-$percent)
        $percent = $percent * 100
        if ($TextFiles.Count -gt 1)
        {
            Write-Progress -Activity 'Importing Language File...' -CurrentOperation $TextFile -PercentComplete $percent -SecondsRemaining $remtime
        }
        $FileName = [System.IO.Path]::GetFileNameWithoutExtension($TextFile)
        [int]$PosDash = $FileName.IndexOf("-")
        $RawObjectID  = $FileName.Substring(0,$posDash)
        $DestFile     = "$Destination\$RawObjectID.txt"
        $SourceFile   = "$Source\$RawObjectID.txt"
        Import-NAVApplicationObjectLanguage -Destination $DestFile -LanguagePath "$LanguageFiles\$TextFile" -Source $SourceFile -Encoding UTF8 -Force *>&1 | tee -filePath $Logfile

        #Transfer Objects to Imported Folder, if successfull
        If (Test-Path -Path "$LogFile")
        {
            $logcontent = Get-Content -Path $LogFile
            Write-Error -Message "Error when importing $TextFile : $logcontent"
        }
        else
        {
            if ($TransferObjects)
            {
                 IF (-Not (Test-Path -Path "$LanguageFiles\Imported"))
                    {
                        New-Item -Path "$LanguageFiles\Imported" -ItemType Directory
                    }
                 Move-Item -Path "$LanguageFiles\$TextFile" -Destination "$LanguageFiles\Imported"
            }
        }
    }
}


@Kowa:
Hast du zufällig eine Funktion um die Sprache von bspw. DEU auf DEA/DES zu ändern via Powershell .

Nein, wenn man das ohne Laufzeitabfrage und quick&dirty machen will, vor dem AppendAllText z.B. für DEU -> DEA einfach

Code:

$line = $line -replace '-A1031-', '-A3079-'

bzw. für DES

Code:

$line = $line -replace '-A1031-', '-A2055-'

davorsetzen.

Sauberer wäre natürlich, die $line dazu noch zu zerlegen und diesen Austausch nur bis zum Doppelpunkt vorzunehmen und dann beide Teile neu zusammenzusetzen.

Inhalte der Captions austauschen für 'ß' -> 'ss' für DES geht zwar prinzipiell auch, aber falls im Add-on auch Textkonstanten mit Inhalten von CONVERTSTR-Funktionen vorhanden sind, dürfen dabei nicht angefasst werden. Das muss also vorher durchleuchtet und ausgeschlossen werden.
Da mit Codepage 850 gelesen wird, kann ansonsten das 'ß' im Code direkt eingegeben werden.

Code:

$line = $line -replace 'ß', 'ss'