gnome-devel-docs master - en to sv translation catalogue (353 entries)

note: (itstool) path: info/desc
en: Other style guides and books about organizing free software projects
sv: Andra stilguider och böcker om att organisera fria programvaruprojekt

note: (itstool) path: page/title
en: Additional Materials
sv: Ytterligare material

note: (itstool) path: page/p
en: Here we give you links to other materials that you may want to read. These will teach you a lot about how to work on large distributed teams of free software developers, and about good programming style in general.
sv: Här ger vi dig länkar till andra material som du kan vilja läsa. Dessa kommer att lära dig mycket om hur du kan arbeta i stora distribuerade grupper av utvecklare av fri programvara, och om god programmeringsstil i allmänhet.

note: (itstool) path: item/p
en: <link href="http://producingoss.com/">Producing Open Source Software</link>, by Karl Fogel. This is a truly excellent book of good practices that free software projects should follow. This is about <em>social aspects</em> of the project: how to treat contributors, how to organize and moderate communication, how to deal with non-profit foundations. If you ask yourself at any time, "how should I deal with $human_situation in the project?", this book may provide the answer.
sv: <link href="http://producingoss.com/">Producing Open Source Software</link>, av Karl Fogel. Detta är en utmärkt bok med god praxis som fria programvaruprojekt bör följa. Detta gäller projektets <em>sociala aspekter</em>: hur bidragsgivare ska behandlas, hur kommunikation ska organiseras och modereras, hur icke vinstdrivande stiftelser ska hanteras. Om du någon gång frågar dig själv ”hur ska jag hantera $mänsklig_situation i projektet?", så har den här boken kanske svaret.

note: (itstool) path: item/p
en: <link href="http://www.gnu.org/prep/standards/">GNU Coding Standards</link>. This is an old document, but it still has lots of excellent advice. It talks about C coding style, issues when dealing with plug-in systems, common option names for command-line programs, conventions for Makefiles, and some very GNU-ish details like using Texinfo for documentation.
sv: <link href="http://www.gnu.org/prep/standards/">GNU Coding Standards</link>. Detta är ett gammalt dokument, men det innehåller ändå massor av utmärkta råd. Det pratar om C-kodstil, problem vid hantering av system för insticksmoduler, vanliga namn på flaggor för kommandoradsprogram, konventioner för Makefiler, och några väldigt GNU-iga detaljer som att använda Texinfo för dokumentation.

note: (itstool) path: item/p
en: <link href="https://www.kernel.org/doc/Documentation/process/coding-style.rst"> Linux Kernel Coding Style</link>. Explains the rationale for "big indentation", brace placement, concise but unambiguous naming, and centralized exit of functions.
sv: <link href="https://www.kernel.org/doc/Documentation/process/coding-style.rst"> Linux Kernel Coding Style</link>. Förklarar den logiska principen bakom ”stor indentering”, parentesplacering, koncisa men otvetydiga namnval, och centraliserade avslut av funktioner.

note: (itstool) path: info/desc
en: Backwards compatibility in APIs
sv: Bakåtkompatibilitet i API:er

note: (itstool) path: page/title
en: API stability
sv: API-stabilitet

note: (itstool) path: synopsis/title
en: Summary
sv: Sammanfattning

note: (itstool) path: item/p
en: Define API stability guarantees for your project. (<link xref="#stability"/>)
sv: Definiera garantier för API-stabilitet för ditt projekt. (<link xref="#stability"/>)

note: (itstool) path: item/p
en: Ensure version numbers are changed as appropriate when API changes. (<link xref="#versioning"/>)
sv: Säkerställ att versionsnummer ändras på lämpligt sätt då API ändras. (<link xref="#versioning"/>)

note: (itstool) path: section/title
en: API and ABI
sv: API och ABI

note: (itstool) path: section/p
en: Examples of API-incompatible changes to a C function would be to add a new parameter, change the function’s return type, or remove a parameter.
sv: Exempel på API-inkompatibla ändringar till en C-funktion skulle vara att lägga till en ny parameter, ändra funktionens returtyp eller att ta bort en parameter.

note: (itstool) path: section/p
en: Other examples of more unusual APIs are configuration file locations and formats, and GSettings schemas. Any changes to these could require code using your library to change.
sv: Andra exempel på mer ovanliga API:er är platser och format för konfigurationsfiler, och GSettings-scheman. Alla ändringar till dessa kan kräva att kod som använder ditt bibliotek behöver ändras.

note: (itstool) path: section/title
en: Stability
sv: Stabilitet

note: (itstool) path: section/p
en: It is possible to apply different levels of API stability to components within a project. For example, the core functions in a library could be stable, and hence their API left unchanged in future; while the newer, less core functions could be left unstable and allowed to change wildly until the right design is found, at which point they could be marked as stable.
sv: Det är möjligt att tillämpa olika nivåer av API-stabilitet till komponenter i ett projekt. Till exempel kan de centrala funktionerna i ett bibliotek vara stabila, och därför kan deras API lämnas oförändrat i framtiden; mindre centrala funktioner skulle kunna lämnas instabila och tillåtas att förändras mycket till dess att rätt design hittats, och vid den tidpunkten skulle de kunna markeras att vara stabila.

note: (itstool) path: section/p
en: Several types of stability commonly considered:
sv: Flera typer av stabilitet som vanligen tas i beaktande:

note: (itstool) path: item/title
en: Unstable
sv: Instabilt

note: (itstool) path: item/p
en: The API could change or be removed in future.
sv: API:t kan ändras eller tas bort i framtiden.

note: (itstool) path: item/title
en: Backwards compatible
sv: Bakåtkompatibelt

note: (itstool) path: item/p
en: Only changes which permit code compiled against the unmodified API to continue running against the modified API are allowed (for example, functions cannot be removed).
sv: Endast ändringar som tillåter kod som kompilerats mot det oförändrade API:t att fortsätta köra mot det ändrade API:t tillåts (till exempel kan inte funktioner tas bort).

note: (itstool) path: item/title
en: Forwards compatible
sv: Framåtkompatibelt

note: (itstool) path: item/p
en: Only changes which permit code compiled against the modified API to run against the unmodified API are allowed (for example, functions cannot be added).
sv: Endast ändringar som tillåter kod som kompilerats mot det ändrade API:t att köra mot det oförändrade API:t tillåts (till exempel kan inte funktioner läggas till).

note: (itstool) path: item/title
en: Totally stable
sv: Fullständigt stabilt

note: (itstool) path: item/p
en: No changes are allowed to the API, only to the implementation.
sv: Inga ändringar tillåts i API:t, endast i implementationen.

note: (itstool) path: section/p
en: Typically, projects commit to backwards-compatibility when they say an API is ‘stable’. Very few projects commit to total stability because it would prevent almost all further development of the project.
sv: Typiskt binder sig projekt till bakåtkompatibilitet då de säger att ett API är ”stabilt”. Väldigt få projekt binder sig till fullständig stabilitet då det skulle förhindra nästan all vidare utveckling av projektet.

note: (itstool) path: section/title (itstool) path: page/title
en: Versioning
sv: Versionering

note: (itstool) path: section/p
en: API stability guarantees are strongly linked to project versioning; both package versioning and libtool versioning. Libtool versioning exists entirely for the purpose of tracking ABI stability, and is explained in detail on the <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link> or <link xref="versioning"/>.
sv: API-stabilitetsgarantier är starkt länkade till projektversionering; både paketversionering och libtool-versionering. Libtool-versionering existerar enbart för syftet att följa ABI-stabilitet, och förklaras i detalj i <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link> eller <link xref="versioning"/>.

note: (itstool) path: section/p
en: API versioning is just as important for D-Bus APIs and GSettings schemas (if they are likely to change) as for C APIs. See the <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">documentation on D-Bus API versioning</link> for details.
sv: API-versionering är precis lika viktig för D-Bus-API:er och GSettings-scheman (om de kan förväntas ändras) som för C-API:er. Se <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">dokumentationen om versionering för D-Bus-API:er</link> för detaljer.

note: (itstool) path: section/p
en: For GIR APIs, their stability typically follows the C API stability, as they are generated from the C API. One complexity is that their stability additionally depends on the version of gobject-introspection used in generating the GIR, but recent versions have not changed much so this is not a major concern.
sv: För GIR-API:er följer stabiliteten typiskt stabiliteten hos C-API:t eftersom de genereras från C-API:t. En komplexitet är att deras stabilitet dessutom beror på versionen av gobject-introspection som använts vid generering av GIR, men senare versioner har inte ändrats mycket, så detta är inget större problem.

note: (itstool) path: section/title
en: External Links
sv: Externa länkar

note: (itstool) path: section/p
en: The topic of API stability is covered in the following articles:
sv: Ämnet API-stabilitet täcks i följande artiklar:

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Application_programming_interface">Wikipedia page on APIs</link>
sv: <link href="https://en.wikipedia.org/wiki/Application_programming_interface">Wikipedia-sidan om API:er</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Application_binary_interface">Wikipedia page on ABIs</link>
sv: <link href="https://en.wikipedia.org/wiki/Application_binary_interface">Wikipedia-sidan om ABI:er</link>

note: (itstool) path: item/p
en: <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">D-Bus API versioning documentation</link>
sv: <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">D-Bus API-versionsdokumentation</link>

note: (itstool) path: info/desc
en: Use of GLib-style asynchronous methods in various situations
sv: Användning av asynkrona metoder av GLib-stil i olika situationer

note: (itstool) path: page/title
en: Asynchronous Programming
sv: Asynkron programmering

note: (itstool) path: item/p
en: Use asynchronous calls in preference to synchronous calls or explicit use of threads (<link xref="#concepts"/>)
sv: Använd asynkrona anrop hellre än synkrona anrop eller explicit användning av trådar (<link xref="#concepts"/>)

note: (itstool) path: item/p
en: Learn and follow the GLib pattern for declaring asynchronous APIs (<link xref="#api-pattern"/>)
sv: Lär dig och följ GLib-mönstret för att deklarera asynkrona API:er (<link xref="#api-pattern"/>)

note: (itstool) path: section/title
en: Concepts
sv: Koncept

note: (itstool) path: section/title
en: API Pattern
sv: API-mönster

note: (itstool) path: section/title
en: Examples of Using Asynchronous Functions
sv: Exempel på användning av asynkrona funktioner

note: (itstool) path: credit/name
en: The GTK+ Team
sv: GTK+-gruppen

note: (itstool) path: info/desc
en: Our guidelines for C code in GNOME
sv: Våra riktlinjer för C-kod i GNOME

note: (itstool) path: page/title
en: C Coding Style
sv: C-kodstil

note: (itstool) path: page/p
en: This document presents the preferred coding style for C programs in GNOME. While coding style is very much a matter of taste, in GNOME we favor a coding style that promotes consistency, readability, and maintainability.
sv: Detta dokument presenterar den föredragna kodstilen för C-program i GNOME. Medan kodstil väldigt mycket är en fråga om smak så föredrar vi i GNOME en kodstil som främjar konsekvens, läsbarhet och lätthet att underhålla.

note: (itstool) path: page/p
en: We present examples of good coding style as well as examples of bad style that is not acceptable in GNOME. Please try to submit patches that conform to GNOME’s coding style; this indicates that you have done your homework to respect the project’s goal of long-term maintainability. Patches with GNOME’s coding style will also be easier to review!
sv: Vi presenterar exempel på bra kodstil så väl som exempel på dålig stil som inte är acceptabel i GNOME. Försök att skicka in patchar som följer GNOME:s kodstil, detta antyder att du gjort din läxa att respektera projektets mål av underhållbarhet i det långa loppet. Patchar med GNOME:s kodstil kommer också vara lättare att granska!

note: (itstool) path: note/p
en: This document is for C code. For other languages, check the <link xref="index">main page</link> of the GNOME Programming Guidelines.
sv: Detta dokument är för C-kod. För andra språk, se <link xref="index">huvudsidan</link> för programmeringsriktlinjerna för GNOME.

note: (itstool) path: page/p
en: These guidelines are heavily inspired by GTK’s CODING-STYLE document, the Linux Kernel’s CodingStyle, and the GNU Coding Standards. These are slight variations of each other, with particular modifications for each project’s particular needs and culture, and GNOME’s version is no different.
sv: Dessa riktlinjer är kraftigt inspirerade av GTK:s dokument CODING-STYLE, Linuxkärnans CodingStyle samt GNU Coding Standards. Dessa är små variationer av varandra, med vissa modifieringar för varje projekts specifika behov och kultur, och GNOME:s version skiljer sig ej från detta.

note: (itstool) path: section/title
en: The Single Most Important Rule
sv: Den absolut viktigaste regeln

note: (itstool) path: section/p
en: The single most important rule when writing code is this: <em>check the surrounding code and try to imitate it</em>.
sv: Den absolut viktigaste regeln vid skrivning av kod är detta: <em>titta på omgivande kod och försök imitera den</em>.

note: (itstool) path: section/p
en: So, whatever this document recommends, if there is already written code and you are patching it, keep its current style consistent even if it is not your favorite style.
sv: Så, vad än detta dokument rekommenderar, om det redan finns skriven kod som du patchar, behåll dess aktuella stil konsekvent även om det inte är din favoritstil.

note: (itstool) path: section/title
en: Line Width
sv: Radbredd

note: (itstool) path: section/p
en: Try to use lines of code between 80 and 120 characters long. This amount of text is easy to fit in most monitors with a decent font size. Lines longer than that become hard to read, and they mean that you should probably restructure your code. If you have too many levels of indentation, it means that you should fix your code anyway.
sv: Försök att använda kodrader från 80 till 120 tecken långa. Denna textmängd passar lätt på de flesta skärmar med en rimlig typsnittsstorlek. Längre rader än så blir svåra att läsa, och betyder att du troligen bör strukturera om din kod. Om du har för många indenteringsnivåer betyder det i vilket fall att du borde fixa till din kod.

note: (itstool) path: section/title
en: Indentation
sv: Indentering

note: (itstool) path: section/p
en: In general there are two preferred indentation styles for code in GNOME.
sv: Allmänt finns det två föredragna indenteringsstilar för kod i GNOME.

note: (itstool) path: section/p
en: Both styles have their pros and cons. The most important things is to <em>be consistent</em> with the surrounding code. For example, the GTK+ library, which is GNOME’s widget toolkit, is written with the GNU style. Nautilus, GNOME’s file manager, is written in Linux kernel style. Both styles are perfectly readable and consistent when you get used to them.
sv: Båda stilarna har sina för- och nackdelar. Det viktigaste är att <em>vara konsekvent</em> med omgivande kod. Exempelvis så är GTK+-biblioteket, GNOME:s komponentverktygslåda, skriven med GNU-stilen. Nautilus, GNOME:s filhanterare, är skriven i Linux-kärnans stil. Båda stilarna är fullständigt läsbara och konsekventa då du vant dig med dem.

note: (itstool) path: section/title
en: Tab Characters
sv: Tabbtecken

note: (itstool) path: section/code
en: 
    /* valid */
    if (condition)
    	single_statement ();
    else
    	another_single_statement (arg1);
sv: 
    /* giltig */
    if (condition)
    	single_statement ();
    else
    	another_single_statement (arg1);

note: (itstool) path: item/code
en: 
    /* valid GNU style */
    if (condition)
      {
        foo ();
        bar ();
      }
    else
      {
        baz ();
      }
sv: 
    /* giltig GNU-stil */
    if (condition)
      {
        foo ();
        bar ();
      }
    else
      {
        baz ();
      }

note: (itstool) path: item/code
en: 
    /* invalid */
    if (condition)
      {
        foo ();
        bar ();
      }
    else
      baz ();
sv: 
    /* ogiltig */
    if (condition)
      {
        foo ();
        bar ();
      }
    else
      baz ();

note: (itstool) path: item/code
en: 
    /* valid Linux kernel style */
    if (condition) {
    	a_single_statement_with_many_arguments (some_lengthy_argument,
    						another_lengthy_argument,
    						and_another_one,
    						plus_one);
    } else
    	another_single_statement (arg1, arg2);
    
    /* valid GNU style */
    if (condition)
      {
        a_single_statement_with_many_arguments (some_lengthy_argument,
                                                another_lengthy_argument,
                                                and_another_one,
                                                plus_one);
      }
    else
      {
        another_single_statement (arg1, arg2);
      }
sv: 
    /* giltig stil för Linux-kärnan */
    if (condition) {
    	a_single_statement_with_many_arguments (some_lengthy_argument,
    						another_lengthy_argument,
    						and_another_one,
    						plus_one);
    } else
    	another_single_statement (arg1, arg2);
    
    /* giltig GNU-stil */
    if (condition)
      {
        a_single_statement_with_many_arguments (some_lengthy_argument,
                                                another_lengthy_argument,
                                                and_another_one,
                                                plus_one);
      }
    else
      {
        another_single_statement (arg1, arg2);
      }

note: (itstool) path: item/code
en: 
    /* valid Linux kernel style */
    if (condition1 ||
        (condition2 &amp;&amp; condition3) ||
        condition4 ||
        (condition5 &amp;&amp; (condition6 || condition7))) {
    	a_single_statement ();
    }
    
    /* valid GNU style */
    if (condition1 ||
        (condition2 &amp;&amp; condition3) ||
        condition4 ||
        (condition5 &amp;&amp; (condition6 || condition7)))
      {
        a_single_statement ();
      }
sv: 
    /* giltig stil för Linux-kärnan */
    if (condition1 ||
        (condition2 &amp;&amp; condition3) ||
        condition4 ||
        (condition5 &amp;&amp; (condition6 || condition7))) {
    	a_single_statement ();
    }
    
    /* giltig GNU-stil */
    if (condition1 ||
        (condition2 &amp;&amp; condition3) ||
        condition4 ||
        (condition5 &amp;&amp; (condition6 || condition7)))
      {
        a_single_statement ();
      }

note: (itstool) path: item/code
en: 
    /* valid Linux kernel style */
    if (condition) {
    	if (another_condition)
    		single_statement ();
    	else
    		another_single_statement ();
    }
    
    /* valid GNU style */
    if (condition)
      {
        if (another_condition)
          single_statement ();
        else
          another_single_statement ();
      }
sv: 
    /* giltig stil för Linux-kärnan */
    if (condition) {
    	if (another_condition)
    		single_statement ();
    	else
    		another_single_statement ();
    }
    
    /* giltig GNU-stil */
    if (condition)
      {
        if (another_condition)
          single_statement ();
        else
          another_single_statement ();
      }

note: (itstool) path: item/code
en: 
    /* invalid */
    if (condition)
    	if (another_condition)
    		single_statement ();
    	else if (yet_another_condition)
    		another_single_statement ();
sv: 
    /* ogiltig */
    if (condition)
    	if (another_condition)
    		single_statement ();
    	else if (yet_another_condition)
    		another_single_statement ();

note: (itstool) path: section/code
en: 
    /* valid Linux kernel style*/
    static void
    my_function (int argument)
    {
    	do_my_things ();
    }
    
    /* valid GNU style*/
    static void
    my_function (int argument)
    {
      do_my_things ();
    }
sv: 
    /* giltig stil för Linux-kärnan*/
    static void
    my_function (int argument)
    {
    	do_my_things ();
    }
    
    /* giltig GNU-stil*/
    static void
    my_function (int argument)
    {
      do_my_things ();
    }

note: (itstool) path: section/code
en: 
    /* invalid */
    static void
    my_function (int argument) {
    	do_my_things ();
    }
    
    /* invalid */
    static void
    my_function (int argument)
      {
        do_my_things ();
      }
sv: 
    /* ogiltig */
    static void
    my_function (int argument) {
    	do_my_things ();
    }
    
    /* ogiltig */
    static void
    my_function (int argument)
      {
        do_my_things ();
      }

note: (itstool) path: section/title
en: Conditions
sv: Villkor

note: (itstool) path: section/code
en: 
    /* invalid */
    if (found == TRUE)
    	do_foo ();
    
    /* invalid */
    if (found == FALSE)
    	do_bar ();
sv: 
    /* ogiltig */
    if (found == TRUE)
    	do_foo ();
    
    /* ogiltig */
    if (found == FALSE)
    	do_bar ();

note: (itstool) path: section/code
en: 
    /* valid */
    if (found)
    	do_foo ();
    
    /* valid */
    if (!found)
    	do_bar ();
sv: 
    /* giltig */
    if (found)
    	do_foo ();
    
    /* giltig */
    if (!found)
    	do_bar ();

note: (itstool) path: section/code
en: 
    /* valid */
    if (some_pointer == NULL)
    	do_blah ();
    
    /* valid */
    if (number == 0)
    	do_foo ();
    
    /* valid */
    if (str != NULL &amp;&amp; *str != '\0')
    	do_bar ();
sv: 
    /* giltig */
    if (some_pointer == NULL)
    	do_blah ();
    
    /* giltig */
    if (number == 0)
    	do_foo ();
    
    /* giltig */
    if (str != NULL &amp;&amp; *str != '\0')
    	do_bar ();

note: (itstool) path: section/code
en: 
    /* invalid */
    if (!some_pointer)
    	do_blah ();
    
    /* invalid */
    if (!number)
    	do_foo ();
    
    /* invalid */
    if (str &amp;&amp; *str)
    	do_bar ();
sv: 
    /* ogiltig */
    if (!some_pointer)
    	do_blah ();
    
    /* ogiltig */
    if (!number)
    	do_foo ();
    
    /* ogiltig */
    if (str &amp;&amp; *str)
    	do_bar ();

note: (itstool) path: section/title
en: Functions
sv: Funktioner

note: (itstool) path: section/p
en: Functions should be declared by placing the returned value on a separate line from the function name:
sv: Funktioner bör deklareras genom att placera det returnerade värdet på en separat rad från funktionsnamnet:

note: (itstool) path: section/p
en: Always put a space before an opening parenthesis but never after:
sv: Placera alltid ett blanksteg före en inledande parentes men aldrig efter:

note: (itstool) path: section/code
en: 
    /* valid */
    if (condition)
    	do_my_things ();
    
    /* valid */
    switch (condition) {
    }
sv: 
    /* giltig */
    if (condition)
    	do_my_things ();
    
    /* giltig */
    switch (condition) {
    }

note: (itstool) path: section/code
en: 
    /* invalid */
    if(condition)
    	do_my_things();
    
    /* invalid */
    if ( condition )
    	do_my_things ( );
sv: 
    /* ogiltig */
    if(condition)
    	do_my_things();
    
    /* ogiltig */
    if ( condition )
    	do_my_things ( );

note: (itstool) path: section/p
en: When declaring a structure type use newlines to separate logical sections of the structure:
sv: Vid deklaration av en strukturtyp, använd nya rader för att separera logiska avsnitt av strukturen:

note: (itstool) path: section/p
en: Do not eliminate whitespace and newlines just because something would fit on a single line:
sv: Ta inte bort blanksteg och nyrader bara för att något skulle rymmas på en enda rad:

note: (itstool) path: section/code
en: 
    /* invalid */
    if (condition) foo (); else bar ();
sv: 
    /* ogiltig */
    if (condition) foo (); else bar ();

note: (itstool) path: section/p
en: Do eliminate trailing whitespace on any line, preferably as a separate patch or commit. Never use empty lines at the beginning or at the end of a file.
sv: Eliminera efterföljande blanksteg på alla rader, förslagsvis som en separat patch eller incheckning. Använd aldrig tomma rader i början eller i slutet på en fil.

note: (itstool) path: section/p
en: This is a little Emacs function that you can use to clean up lines with trailing whitespace:
sv: Det här är en liten Emacs-funktion som du kan använda för att rensa rader med efterföljande blanksteg:

note: (itstool) path: section/code
en: 
    (defun clean-line-ends ()
      (interactive)
      (if (not buffer-read-only)
          (save-excursion
    	(goto-char (point-min))
    	(let ((count 0))
    	  (while (re-search-forward "[ 	]+$" nil t)
    	    (setq count (+ count 1))
    	    (replace-match "" t t))
    	  (message "Cleaned %d lines" count)))))
sv: 
    (defun clean-line-ends ()
      (interactive)
      (if (not buffer-read-only)
          (save-excursion
    	(goto-char (point-min))
    	(let ((count 0))
    	  (while (re-search-forward "[ 	]+$" nil t)
    	    (setq count (+ count 1))
    	    (replace-match "" t t))
    	  (message "Rensade %d rader" count)))))

note: (itstool) path: section/title
en: The <code>switch</code> Statement
sv: <code>switch</code>-satsen

note: (itstool) path: section/code
en: 
    /* valid Linux kernel style */
    switch (condition) {
    case FOO:
    	do_foo ();
    	break;
    
    case BAR:
    	do_bar ();
    	break;
    }
    
    /* valid GNU style */
    switch (condition)
      {
      case FOO:
        do_foo ();
        break;
    
      case BAR:
        do_bar ();
        break;
      }
sv: 
    /* giltig stil för Linux-kärnan */
    switch (condition) {
    case FOO:
    	do_foo ();
    	break;
    
    case BAR:
    	do_bar ();
    	break;
    }
    
    /* giltig GNU-stil */
    switch (condition)
      {
      case FOO:
        do_foo ();
        break;
    
      case BAR:
        do_bar ();
        break;
      }

note: (itstool) path: section/code
en: 
    /* invalid */
    switch (condition) {
      case FOO: do_foo (); break;
      case BAR: do_bar (); break;
    }
    
    /* invalid */
    switch (condition)
      {
      case FOO: do_foo ();
        break;
      case BAR: do_bar ();
        break;
      }
    
    /* invalid */
    switch (condition)
      {
        case FOO:
        do_foo ();
        break;
        case BAR:
        do_bar ();
        break;
      }
sv: 
    /* ogiltig */
    switch (condition) {
      case FOO: do_foo (); break;
      case BAR: do_bar (); break;
    }
    
    /* ogiltig */
    switch (condition)
      {
      case FOO: do_foo ();
        break;
      case BAR: do_bar ();
        break;
      }
    
    /* ogiltig */
    switch (condition)
      {
        case FOO:
        do_foo ();
        break;
        case BAR:
        do_bar ();
        break;
      }

note: (itstool) path: section/p
en: It is preferable, though not mandatory, to separate the various cases with a newline:
sv: Det är önskvärt, men inte obligatoriskt, att separera de olika case-alternativen med en nyrad:

note: (itstool) path: section/p
en: The <code>break</code> statement for the <code>default</code> case is not mandatory.
sv: <code>break</code>-satsen för <code>default</code>-fallet är inte obligatorisk.

note: (itstool) path: section/code
en: 
    /* valid GNU style */
    switch (condition)
      {
      case FOO:
        {
          int foo;
    
          foo = do_foo ();
        }
        break;
    
      …
      }
sv: 
    /* giltig GNU-stil */
    switch (condition)
      {
      case FOO:
        {
          int foo;
    
          foo = do_foo ();
        }
        break;
    
      …
      }

note: (itstool) path: section/title
en: Header Files
sv: Headerfiler

note: (itstool) path: section/p
en: The only major rule for headers is that the function definitions should be vertically aligned in three columns:
sv: Den enda stora regeln för headerfiler är att funktionsdefinitionerna bör vara vertikalt justerade i tre kolumner:

note: (itstool) path: section/p
en: The maximum width of each column is given by the longest element in the column:
sv: Den maximala bredden för varje kolumn ges av det längsta elementet i kolumnen:

note: (itstool) path: section/p
en: It is also possible to align the columns to the next tab:
sv: Det är också möjligt att justera kolumnerna till nästa tabb:

note: (itstool) path: section/p
en: As before, you can use <code>M-x align</code> in Emacs to do this automatically.
sv: Som tidigare kan du använda <code>M-x align</code> i Emacs för att göra detta automatiskt.

note: (itstool) path: section/title
en: GObject Classes
sv: GObject-klasser

note: (itstool) path: section/p
en: Interfaces must have the following macros:
sv: Gränssnitt måste ha följande makron:

note: (itstool) path: td/p
en: Macro
sv: Makro

note: (itstool) path: td/p
en: Expands to
sv: Expanderas till

note: (itstool) path: section/title
en: Memory Allocation
sv: Minnesallokering

note: (itstool) path: section/p
en: See <link xref="memory-management"/> for more details.
sv: Se <link xref="memory-management"/> för mer detaljer.

note: (itstool) path: section/title
en: Macros
sv: Makron

note: (itstool) path: section/title
en: Public API
sv: Öppet API

note: (itstool) path: section/title
en: Private API
sv: Privat API

note: (itstool) path: section/p
en: Underscore-prefixed functions are never exported.
sv: Funktioner som inleds med understreck exporteras aldrig.

note: (itstool) path: section/p
en: Non-exported functions that are only needed in one source file should be declared static.
sv: Ej exporterade funktioner som bara behövs i en källkodsfil bör deklareras static.

note: (itstool) path: p/link
en: Creative Commons Attribution-Share Alike 3.0 United States License
sv: Creative Commons Erkännande-DelaLika 3.0 Förenta Staterna

note: (itstool) path: license/p
en: This work is licensed under a <_:link-1/>.
sv: Detta verk är licensierat under licensen <_:link-1/>.

note: (itstool) path: license/p
en: As a special exception, the copyright holders give you permission to copy, modify, and distribute the example code contained in this document under the terms of your choosing, without restriction.
sv: Som ett speciellt undantag, ger upphovsrättsinnehavarna dig tillåtelse att kopiera, modifiera och distribuera exempelkoden som finns i detta dokument under de villkor som du väljer, utan restriktioner.

note: (itstool) path: info/desc
en: Simple persistent object stores
sv: Enkla beständiga objektlagringar

note: (itstool) path: page/title
en: Databases
sv: Databaser

note: (itstool) path: item/p
en: Use databases for appropriate use cases: not configuration data (use GSettings). (<link xref="#when-to-use-databases"/>)
sv: Använd databaser för lämpliga användningsområden: inte konfigurationsdata (använd GSettings). (<link xref="#when-to-use-databases"/>)

note: (itstool) path: item/p
en: Choose between GOM and GVDB based on whether indexing is required. (<link xref="#when-to-use-databases"/>)
sv: Välj mellan GOM och GVDB beroende på om indexering krävs. (<link xref="#when-to-use-databases"/>)

note: (itstool) path: item/p
en: Avoid SQL injection vulnerabilities by using prepared statements. (<link xref="#sql-injection"/>)
sv: Undvik SQL-injektionssårbarheter genom att använda förberedda satser. (<link xref="#sql-injection"/>)

note: (itstool) path: section/title
en: When to Use Databases
sv: När databaser bör användas

note: (itstool) path: section/p
en: GOM should be used if you need advanced features, especially indexing. GVDB should be used otherwise.
sv: GOM bör användas om du behöver avancerade funktioner, i synnerhet indexering. I annat fall bör GVDB användas.

note: (itstool) path: section/title
en: Using GOM
sv: Använda GOM

note: (itstool) path: section/p
en: Providing a GOM tutorial is beyond the scope of this document, but a <link href="https://developer.gnome.org/gom/">reference manual is available</link>.
sv: Att tillhandahålla en GOM-handledning är utanför ändamålet för detta dokument, men en <link href="https://developer.gnome.org/gom/">referenshandbok finns tillgänglig</link>.

note: (itstool) path: section/title
en: SQL Injection
sv: SQL-injektion

note: (itstool) path: section/title
en: Using GVDB
sv: Använda GVDB

note: (itstool) path: section/p
en: GVDB has a simple API which mirrors a conventional hash table. Presently, GVDB is only available as a copy-and-paste library; fetch the most recent copy of the code from <link href="https://gitlab.gnome.org/GNOME/gvdb">GVDB git</link> and copy it into your project. It is licensed under LGPLv2.1+.
sv: GVDB har ett enkelt API som speglar en konventiell hashtabell. För närvarande finns GVDB endast tillgängligt som ett kopiera-och-klistra-bibliotek; hämta den senaste versionen av koden från <link href="https://gitlab.gnome.org/GNOME/gvdb">GVDB:s git</link> och kopiera den till ditt projekt. Det är licensierat under LGPLv2.1+.

note: (itstool) path: section/p
en: A full GVDB tutorial is beyond the scope of this document.
sv: En fullständig GVDB-handledning är utanför ändamålet för detta dokument.

note: (itstool) path: info/desc
en: Adding documentation to libraries and APIs
sv: Lägga till dokumentation till bibliotek och API:er

note: (itstool) path: page/title (itstool) path: section/title
en: Documentation
sv: Dokumentation

note: (itstool) path: item/p
en: Use gtk-doc with up-to-date settings for API documentation. (<link xref="#gtk-doc"/>)
sv: Använd gtk-doc med uppdaterade inställningar för API-dokumentation. (<link xref="#gtk-doc"/>)

note: (itstool) path: item/p
en: Use XML entities for including external symbols into the documentation. (<link xref="#build-system"/>)
sv: Använd XML-entiteter för att inkludera externa symboler i dokumentationen. (<link xref="#build-system"/>)

note: (itstool) path: item/p
en: Use <cmd>gdbus-codegen</cmd> to generate D-Bus API documentation to include in the gtk-doc build. (<link xref="#dbus-api"/>)
sv: Använd <cmd>gdbus-codegen</cmd> för att generera D-Bus-API-dokumentation att inkludera i gtk-doc-bygget. (<link xref="#dbus-api"/>)

note: (itstool) path: item/p
en: Add <code>Since</code> lines to all API documentation. (<link xref="#symbol-versioning"/>)
sv: Lägg till <code>Since</code>-rader till all API-dokumentation. (<link xref="#symbol-versioning"/>)

note: (itstool) path: item/p
en: Enable gtk-doc tests. (<link xref="#keeping-up-to-date"/>)
sv: Aktivera gtk-doc-tester. (<link xref="#keeping-up-to-date"/>)

note: (itstool) path: section/title
en: Build System
sv: Byggsystem

note: (itstool) path: section/title
en: Standard Layout
sv: Standardlayout

note: (itstool) path: section/p
en: The following layout is suggested:
sv: Den följande layouten föreslås:

note: (itstool) path: listing/title
en: <file><var>project-name</var>-docs.xml</file>
sv: <file><var>projektnamn</var>-docs.xml</file>

note: (itstool) path: section/title
en: Licensing
sv: Licensiering

note: (itstool) path: section/title
en: Public APIs
sv: Öppna API:er

note: (itstool) path: section/p
en: All public APIs must have gtk-doc comments. For functions, these should be placed in the source file, directly above the function.
sv: Alla öppna API:er måste ha gtk-doc-kommentarer. För funktioner bör dessa placeras i källkodsfilen, direkt ovanför funktionen.

note: (itstool) path: section/p
en: Instead of:
sv: Istället för:

note: (itstool) path: section/p
en: For more information on introspection, see the <link xref="introspection">introspection guidelines</link>.
sv: För mer information om introspektion, se <link xref="introspection">riktlinjerna för introspektion</link>.

note: (itstool) path: section/title
en: Symbol Versioning
sv: Symbolversionering

note: (itstool) path: section/p (itstool) path: example/p
en: For example:
sv: Till exempel:

note: (itstool) path: section/title
en: D-Bus APIs
sv: D-Bus-API:er

note: (itstool) path: section/title
en: Keeping Documentation Up to Date
sv: Hålla dokumentation uppdaterad

note: (itstool) path: section/p
en: They will then be run as part of <cmd>make check</cmd>.
sv: De kommer sedan att köras som en del av <cmd>make check</cmd>.

note: (itstool) path: info/desc
en: Accessing the file system
sv: Komma åt filsystemet

note: (itstool) path: page/title
en: File System Access
sv: Filsystemsåtkomst

note: (itstool) path: synopsis/p
en: There are a few anti-patterns to consider when accessing the file system. This article assumes knowledge of the standard <link href="https://developer.gnome.org/gio/stable/GFile.html"><code>GFile</code></link>, <link href="https://developer.gnome.org/gio/stable/GInputStream.html"><code>GInputStream</code></link> and <link href="https://developer.gnome.org/gio/stable/GOutputStream.html"><code>GOutputStream</code></link> APIs.
sv: Det finns några få antimönster att överväga vid åtkomst till filsystemet. Denna artikel antar kunskap om standard-API:erna för <link href="https://developer.gnome.org/gio/stable/GFile.html"><code>GFile</code></link>, <link href="https://developer.gnome.org/gio/stable/GInputStream.html"><code>GInputStream</code></link> och <link href="https://developer.gnome.org/gio/stable/GOutputStream.html"><code>GOutputStream</code></link>.

note: (itstool) path: item/p
en: Always use appropriate functions to construct file names and paths. (<link xref="#file-path-construction"/>)
sv: Använd alltid lämpliga funktioner för att konstruera filnamn och sökvägar. (<link xref="#file-path-construction"/>)

note: (itstool) path: item/p
en: Validate file paths are in the expected directories before using them. (<link xref="#path-validation-and-sandboxing"/>)
sv: Validera att sökvägar till filer är i de förväntade katalogerna innan de används. (<link xref="#path-validation-and-sandboxing"/>)

note: (itstool) path: example/p
en: For example, file paths should be built using <link href="https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-build-filename"><code>g_build_filename()</code></link> rather than <link href="https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-strconcat"><code>g_strconcat()</code></link>.
sv: Till exempel bör filsökvägar byggas med <link href="https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-build-filename"><code>g_build_filename()</code></link> snarare än <link href="https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-strconcat"><code>g_strconcat()</code></link>.

note: (itstool) path: section/title
en: GError Usage
sv: GError-användning

note: (itstool) path: info/desc
en: Linked lists and container types
sv: Länkade listor och behållartyper

note: (itstool) path: section/title
en: GList Usage
sv: GList-användning

note: (itstool) path: section/code
en: GList *some_list, *l;
    
    for (l = some_list; l != NULL; l = l-&gt;next)
      {
        gpointer element_data = l-&gt;data;
    
        /* Do something with @element_data. */
      }
sv: GList *some_list, *l;
    
    for (l = some_list; l != NULL; l = l-&gt;next)
      {
        gpointer element_data = l-&gt;data;
    
        /* Gör något med @element_data. */
      }

note: (itstool) path: section/code
en: GList *some_list;
    guint i;
    
    /* This code is inefficient and should not be used in production. */
    for (i = 0; i &lt; g_list_length (some_list); i++)
      {
        gpointer element_data = g_list_nth_data (some_list, i);
    
        /* Do something with @element_data. */
      }
sv: GList *some_list;
    guint i;
    
    /* Denna kod är ineffektiv och bör inte användas professionellt. */
    for (i = 0; i &lt; g_list_length (some_list); i++)
      {
        gpointer element_data = g_list_nth_data (some_list, i);
    
        /* Gör något med @element_data. */
      }

note: (itstool) path: section/code
en: GPtrArray *some_array;
    guint i;
    
    for (i = 0; i &lt; some_array-&gt;len; i++)
      {
        gpointer element_data = some_array-&gt;pdata[i];
    
        /* Do something with @element_data. */
      }
sv: GPtrArray *some_array;
    guint i;
    
    for (i = 0; i &lt; some_array-&gt;len; i++)
      {
        gpointer element_data = some_array-&gt;pdata[i];
    
        /* Gör något med @element_data. */
      }

note: (itstool) path: info/desc (itstool) path: page/title
en: GNOME Programming Guidelines
sv: Programmeringsriktlinjer för GNOME

[ctx: link:trail]
note: (itstool) path: info/title
en: Programming Guidelines
sv: Programmeringsriktlinjer

note: (itstool) path: page/p
en: This article contains several guidelines and suggestions for programmers working in and with the GNOME stack. This is intended for programmers to know about the development processes, conventions and philosophies behind GNOME applications and the stack of libraries supporting them. By knowing “the way things are done” in the GNOME ecosystem, it is hoped that programmers will find use of GNOME APIs and development of new applications easier and more natural, and will produce code which is legible and maintainable over a long period of time by a diverse team of programmers.
sv: Denna artikel innehåller flera riktlinjer och förslag för programmerare som arbetar i och med GNOME-stacken. Den avser att programmerare ska känna till utvecklingsprocesser, konventioner och filosofier bakom GNOME-program och stacken av bibliotek som stöder dem. Genom att veta ”hur saker görs” i GNOME-ekosystemet hoppas vi att programmerare kommer finna användning av GNOME-API:er och utveckling av nya program lättare och mer naturlig, och kommer att producera kod som är läsbar och kan underhållas under lång tid av en stor grupp programmerare.

note: (itstool) path: page/p
en: This guide has a two-fold purpose:
sv: Denna guide har ett dubbelt syfte:

note: (itstool) path: item/p
en: To give you good suggestions on how to write code for GNOME or using GNOME technologies. This will help you write code that is consistent with best practices, and that will be accepted by the community. This will also lead to code that is a pleasure to work on.
sv: Att ge dig goda förslag på hur du kan skriva kod för GNOME eller använda GNOME-teknologier. Detta kommer att hjälpa dig skriva kod som följer god praxis och kommer att accepteras av gemenskapen. Detta kommer också leda till kod som är ett nöje att arbeta med.

note: (itstool) path: item/p
en: To transmit the knowledge we have gotten over the years on how to keep the GNOME project sustainable, even when people’s contributions increase or decrease.
sv: Att överföra kunskapen som vi har samlat under åren om hur GNOME-projektet kan förbli hållbart, även då folks bidrag ökar eller minskar.

[ctx: link:trail]
note: (itstool) path: info/title
en: General Guidelines
sv: Allmänna riktlinjer

note: (itstool) path: section/title
en: General Guidelines
sv: Allmänna riktlinjer

[ctx: link:trail]
note: (itstool) path: info/title
en: Maintainer Guidelines
sv: Riktlinjer för paketansvariga

note: (itstool) path: section/title
en: Maintainer Guidelines
sv: Riktlinjer för paketansvariga

[ctx: link:trail]
note: (itstool) path: info/title
en: Specific How-Tos
sv: Specifika guider

note: (itstool) path: section/title
en: Specific How-Tos
sv: Specifika guider

[ctx: link:trail]
note: (itstool) path: info/title
en: References
sv: Referenser

note: (itstool) path: section/title
en: References
sv: Referenser

note: (itstool) path: info/desc
en: GObject Introspection support in library code
sv: GObject-introspektionsstöd i bibliotekskod

note: (itstool) path: page/title
en: Introspection
sv: Introspektion

note: (itstool) path: item/p
en: Enable introspection for all libraries. (<link xref="#using-introspection"/>)
sv: Aktivera introspektion för alla bibliotek. (<link xref="#using-introspection"/>)

note: (itstool) path: item/p
en: Design APIs to be introspectable from the start. (<link xref="#api-design"/>)
sv: Designa API:er för att vara introspekterbara från första början. (<link xref="#api-design"/>)

note: (itstool) path: section/title
en: Using Introspection
sv: Använda introspektion

note: (itstool) path: section/title
en: API Design
sv: API-design

note: (itstool) path: info/desc
en: Logging debug and information output from libraries and programs
sv: Logga felsöknings- och informationsutdata från bibliotek och program

note: (itstool) path: page/title
en: Logging
sv: Loggning

note: (itstool) path: item/p
en: Use the GLib logging framework instead of logging directly to stderr and stdout. (<link xref="#glib-logging-framework"/>)
sv: Använd GLibs ramverk för loggning istället för att logga direkt till stderr och stdout. (<link xref="#glib-logging-framework"/>)

note: (itstool) path: item/p
en: Do not implement log rotation and deletion; leave that to system services. (<link xref="#log-rotation"/>)
sv: Implementera inte rotation och borttagning av loggar, lämna det till systemtjänster. (<link xref="#log-rotation"/>)

note: (itstool) path: section/title
en: GLib Logging Framework
sv: GLib-ramverk för loggning

note: (itstool) path: item/p
en: Multiple logging domains, which can be processed separately.
sv: Flera loggningsdomäner, vilka kan bearbetas separat.

note: (itstool) path: section/title
en: Exceptions
sv: Undantag

note: (itstool) path: item/p
en: Do not use <code>g_warning()</code> in library code. Use <link xref="gerror"><code>GError</code>s</link> instead.
sv: Använd inte <code>g_warning()</code> i bibliotekskod. Använd <link xref="gerror"><code>GError</code></link> istället.

note: (itstool) path: section/title
en: journald Integration
sv: journald-integration

note: (itstool) path: section/p
en: For more information, see this <link href="http://0pointer.de/blog/projects/journal-submit.html">article on logging to the journal</link>.
sv: För mer information, se denna <link href="http://0pointer.de/blog/projects/journal-submit.html">artikel om att logga till journalen</link>.

note: (itstool) path: section/title
en: Log Rotation
sv: Rotation av loggar

note: (itstool) path: item/p
en: Use <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> to run a function in the background without caring about the specific thread used (<link xref="#gtask"/>)
sv: Använd <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> för att köra en funktion i bakgrunden utan att bry dig om vilken specifik tråd som används (<link xref="#gtask"/>)

note: (itstool) path: section/title
en: What is <code>GMainContext</code>?
sv: Vad är <code>GMainContext</code>?

note: (itstool) path: section/p
en: This is <link href="https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#mainloop-states">explained very well</link> in the <link href="https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#GSourceFuncs">GLib documentation</link>.
sv: Detta <link href="https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#mainloop-states">förklaras väldigt bra</link> i <link href="https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#GSourceFuncs">dokumentationen för GLib</link>.

note: (itstool) path: section/title
en: What is <code>GMainLoop</code>?
sv: Vad är <code>GMainLoop</code>?

note: (itstool) path: td/p
en: Do not use
sv: Använd inte

note: (itstool) path: td/p
en: Use instead
sv: Använd istället

note: (itstool) path: section/title
en: Using <code>GMainContext</code> in a Library
sv: Använda <code>GMainContext</code> i ett bibliotek

note: (itstool) path: example/p
en: The example below demonstrates the underlying principles, but there are convenience methods explained below which simplify things.
sv: Exemplet nedan demonstrerar de underliggande principerna, men det finns bekvämlighetsmetoder förklarade nedan vilka förenklar saker.

note: (itstool) path: section/title
en: Convenience Method: <code>g_main_context_invoke_full()</code>
sv: Bekvämlighetsmetod: <code>g_main_context_invoke_full()</code>

note: (itstool) path: example/p
en: The following can be used:
sv: Så kan följande användas:

note: (itstool) path: info/desc
en: Managing memory allocation and deallocation in C
sv: Hantera minnesallokering och avallokering i C

note: (itstool) path: page/title
en: Memory Management
sv: Minneshantering

note: (itstool) path: synopsis/p
en: There are three situations to avoid, in order of descending importance:
sv: Det finns tre situationer att undvika, i sjunkande viktighetsordning:

note: (itstool) path: item/p
en: Using memory after freeing it (use-after-free).
sv: Använda minne efter att det frigjorts (use-after-free).

note: (itstool) path: item/p
en: Using memory before allocating it.
sv: Använda minne innan det allokerats.

note: (itstool) path: item/p
en: Not freeing memory after allocating it (leaking).
sv: Inte frigöra minne efter att ha allokerat det (läckor).

note: (itstool) path: synopsis/p
en: Key principles, in no particular order:
sv: Nyckelprinciper utan inbördes ordning:

note: (itstool) path: section/title
en: Principles of Memory Management
sv: Principer för minneshantering

note: (itstool) path: section/p
en: For example, consider the functions:
sv: Betänk exempelvis följande funktioner:

note: (itstool) path: td/p
en: Function name
sv: Funktionsnamn

note: (itstool) path: td/p
en: Convention 1 (standard)
sv: Konvention 1 (standard)

note: (itstool) path: td/p
en: Convention 2 (alternate)
sv: Konvention 2 (alternativ)

note: (itstool) path: td/p
en: Convention 3 (<cmd>gdbus-codegen</cmd>)
sv: Konvention 3 (<cmd>gdbus-codegen</cmd>)

note: (itstool) path: section/title
en: Convenience Functions
sv: Bekvämlighetsfunktioner

note: (itstool) path: section/p
en: See <link xref="tooling#valgrind"/> for more information on using Valgrind.
sv: Se <link xref="tooling#valgrind"/> för mer information om att använda Valgrind.

note: (itstool) path: info/desc
en: Avoiding symbol conflicts between libraries by namespacing all APIs
sv: Undvika symbolkonflikter mellan bibliotek genom att använda namnrymder för alla API:er

note: (itstool) path: page/title
en: Namespacing
sv: Namnrymder

note: (itstool) path: section/title
en: GObject APIs
sv: GObject-API:er

note: (itstool) path: info/desc
en: Writing libraries to be future proof through parallel installation
sv: Skriva paket för att vara framtidssäkra genom parallell installation

note: (itstool) path: page/title
en: Parallel Installability
sv: Parallell installerbarhet

note: (itstool) path: synopsis/p
en: If two packages can be parallel installed, then they have no filenames in common, and people developing against the package always compile against the version they expected. This applies to daemons, utility programs and configuration files as it does to header files and library binaries.
sv: Om två paket kan installeras parallellt så har de inga filnamn gemensamt, och folk som utvecklar mot paketet kompilerar alltid mot versionen de förväntar sig. Detta gäller demoner, nyttoprogram och konfigurationsfiler så väl som headerfiler och biblioteksbinärer.

note: (itstool) path: item/p
en: Ensure all versions of a library are parallel installable. (<link xref="#justification"/>)
sv: Säkerställ att alla versioner av ett bibliotek är parallellt installerbara. (<link xref="#justification"/>)

note: (itstool) path: item/p
en: Version all files installed by a library. (<link xref="#solution"/>)
sv: Versionera alla filer som installeras av ett bibliotek. (<link xref="#solution"/>)

note: (itstool) path: section/title
en: Solution
sv: Lösning

note: (itstool) path: section/p
en: The solution to the problem is essentially to rename the library, and in most cases the nicest way to do so is to include the version number in the path of every file it installs. This means multiple versions of the library can be installed at the same time.
sv: Lösningen på problemet är i princip att byta namn på biblioteket, och i de flesta fall är bästa sättet att göra detta att inkludera versionsnumret i sökvägen för varje fil det installerar. Detta betyder att flera versioner av biblioteket kan installeras samtidigt.

note: (itstool) path: section/p
en: For example, say that library <code>Foo</code> traditionally installs these files:
sv: Säg till exempel att biblioteket <code>Foo</code> traditionellt installerar dessa filer:

note: (itstool) path: section/p
en: You might modify <code>Foo</code> version 4 to install these files instead:
sv: Du skulle kunna modifiera <code>Foo</code> version 4 så att det istället installerar dessa filer:

note: (itstool) path: section/p
en: It could then be parallel installed with version 5:
sv: Det skulle sedan kunna installeras parallellt med version 5:

note: (itstool) path: section/title
en: Version Numbers
sv: Versionsnummer

note: (itstool) path: section/title
en: Libraries
sv: Bibliotek

note: (itstool) path: section/p
en: Versioned libraries can be built and installed from automake using the following code:
sv: Versionerade bibliotek kan byggas och installeras från automake med följande kod:

note: (itstool) path: listing/title
en: Libraries in Automake
sv: Bibliotek i Automake

note: (itstool) path: listing/desc
en: Code to build and install versioned libraries from <file>Makefile.am</file>
sv: Kod för att bygga och installera versionerade bibliotek från <file>Makefile.am</file>

note: (itstool) path: section/title
en: Configuration Files
sv: Konfigurationsfiler

note: (itstool) path: section/title
en: Gettext Translations
sv: Gettext-översättningar

note: (itstool) path: section/title
en: D-Bus Interfaces
sv: D-Bus-gränssnitt

note: (itstool) path: list/title
en: Service Names
sv: Tjänstenamn

note: (itstool) path: list/title
en: Interface Names
sv: Gränssnittsnamn

note: (itstool) path: list/title
en: Object Paths
sv: Objektsökvägar

note: (itstool) path: section/p
en: these should be versioned as:
sv: så bör dessa versioneras som:

note: (itstool) path: item/title
en: Validation
sv: Validering

note: (itstool) path: info/desc
en: Moving computation out of the main thread into worker threads
sv: Flytta beräkning ut ur huvudtråden till arbetstrådar

note: (itstool) path: page/title
en: Threading
sv: Trådning

note: (itstool) path: item/p
en: Do not use threads if at all possible. (<link xref="#when-to-use-threading"/>)
sv: Använd inte trådar om det är möjligt att undvika. (<link xref="#when-to-use-threading"/>)

note: (itstool) path: item/p
en: If threads have to be used, use <code>GTask</code> or <code>GThreadPool</code> and isolate the threaded code as much as possible. (<link xref="#using-threading"/>)
sv: Om trådar måste användas, använd <code>GTask</code> eller <code>GThreadPool</code> och isolera den trådade koden så mycket som möjligt. (<link xref="#using-threading"/>)

note: (itstool) path: item/p
en: Use <code>g_thread_join()</code> to avoid leaking thread resources if using <code>GThread</code> manually. (<link xref="#using-threading"/>)
sv: Använd <code>g_thread_join()</code> för att undvika att läcka trådresurser om du använder <code>GThread</code> manuellt. (<link xref="#using-threading"/>)

note: (itstool) path: section/title
en: When to Use Threading
sv: När trådning ska användas

note: (itstool) path: example/p
en: With an implementation something like:
sv: Med en implementering i stil med:

note: (itstool) path: example/p
en: See the <link href="https://developer.gnome.org/gio/stable/GAsyncResult.html"><code>GAsyncResult</code> documentation</link> for more details. A simple way to implement the worker thread is to use <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> and <link href="https://developer.gnome.org/gio/stable/GTask.html#g-task-run-in-thread"><code>g_task_run_in_thread()</code></link>. (See also: <link xref="main-contexts#gtask"/>.)
sv: Se <link href="https://developer.gnome.org/gio/stable/GAsyncResult.html">dokumentationen för <code>GAsyncResult</code></link> för mer detaljer. Ett enkelt sätt att implementera arbetstråden är att använda <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> och <link href="https://developer.gnome.org/gio/stable/GTask.html#g-task-run-in-thread"><code>g_task_run_in_thread()</code></link>. (Se även: <link xref="main-contexts#gtask"/>.)

note: (itstool) path: section/title
en: Using Threading
sv: Använda trådning

note: (itstool) path: section/title
en: Debugging
sv: Felsökning

note: (itstool) path: info/desc
en: Using the right tool for various tasks
sv: Använda rätt verktyg för olika uppgifter

note: (itstool) path: page/title
en: Tooling
sv: Verktyg

note: (itstool) path: item/p
en: Compile frequently with a second compiler. (<link xref="#gcc-and-clang"/>)
sv: Kompilera regelbundet med en andra kompilator. (<link xref="#gcc-and-clang"/>)

note: (itstool) path: item/p
en: Enable a large selection of compiler warnings and make them fatal. (<link xref="#gcc-and-clang"/>)
sv: Aktivera ett stort urval av kompilatorvarningar och gör dem ödesdigra. (<link xref="#gcc-and-clang"/>)

note: (itstool) path: item/p
en: Use GDB to debug and step through code. (<link xref="#gdb"/>)
sv: Använd GDB för att felsöka och stega igenom kod. (<link xref="#gdb"/>)

note: (itstool) path: section/title
en: GCC and Clang
sv: GCC och Clang

note: (itstool) path: item/p
en: Copy <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> to the <file>m4/</file> directory of your project.
sv: Kopiera <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> till <file>m4/</file>-katalogen för ditt projekt.

note: (itstool) path: item/p
en: Add <code>AX_VALGRIND_CHECK</code> to <file>configure.ac</file>.
sv: Lägg till <code>AX_VALGRIND_CHECK</code> till <file>configure.ac</file>.

note: (itstool) path: item/p
en: Add <code>@VALGRIND_CHECK_RULES@</code> to the <file>Makefile.am</file> in each directory which contains unit tests.
sv: Lägg till <code>@VALGRIND_CHECK_RULES@</code> till <file>Makefile.am</file> i varje katalog som innehåller enhetstester.

note: (itstool) path: section/p
en: To run memcheck manually on an installed program, use:
sv: För att köra memcheck manuellt på ett installerat program, använd:

note: (itstool) path: section/p
en: <cmd>valgrind --tool=memcheck --leak-check=full <var>my-program-name</var></cmd>
sv: <cmd>valgrind --tool=memcheck --leak-check=full <var>mitt-programnamn</var></cmd>

note: (itstool) path: section/p
en: <cmd>libtool exec valgrind --tool=memcheck --leak-check=full <var>./my-program-name</var></cmd>
sv: <cmd>libtool exec valgrind --tool=memcheck --leak-check=full <var>./mitt-programnamn</var></cmd>

note: (itstool) path: section/p
en: A full tutorial on using memcheck is <link href="http://valgrind.org/docs/manual/mc-manual.html">here</link>.
sv: En fullständig handledning i att använda memcheck finns <link href="http://valgrind.org/docs/manual/mc-manual.html">här</link>.

note: (itstool) path: section/title
en: cachegrind and KCacheGrind
sv: cachegrind och KCacheGrind

note: (itstool) path: section/p
en: A full tutorial on using cachegrind is <link href="http://valgrind.org/docs/manual/cg-manual.html">here</link>.
sv: En fullständig handledning i att använda cachegrind finns <link href="http://valgrind.org/docs/manual/cg-manual.html">här</link>.

note: (itstool) path: section/title
en: helgrind and drd
sv: helgrind och drd

note: (itstool) path: section/p
en: Full tutorials on using helgrind and drd are <link href="http://valgrind.org/docs/manual/hg-manual.html">here</link> and <link href="http://valgrind.org/docs/manual/drd-manual.html"> here</link>.
sv: Fullständiga handledningar i att använda helgrind and drd finns <link href="http://valgrind.org/docs/manual/hg-manual.html">här</link> och <link href="http://valgrind.org/docs/manual/drd-manual.html"> här</link>.

note: (itstool) path: section/p
en: As it is experimental, sgcheck must be run by passing <cmd>--tool=exp-sgcheck</cmd> to Valgrind, rather than <cmd>--tool=sgcheck</cmd>.
sv: Eftersom den är experimentell måste sgcheck köras genom att skicka <cmd>--tool=exp-sgcheck</cmd> till Valgrind snarare än <cmd>--tool=sgcheck</cmd>.

note: (itstool) path: section/p
en: A full tutorial on using sgcheck is <link href="http://valgrind.org/docs/manual/sg-manual.html">here</link>.
sv: En fullständig handledning i att använda sgcheck finns <link href="http://valgrind.org/docs/manual/sg-manual.html">här</link>.

note: (itstool) path: section/title
en: gcov and lcov
sv: gcov och lcov

note: (itstool) path: section/p
en: To add <code>AX_CODE_COVERAGE</code> support to a project:
sv: För att lägga till stöd för <code>AX_CODE_COVERAGE</code> till ett projekt:

note: (itstool) path: item/p
en: Copy <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> to the <file>m4/</file> directory of your project.
sv: Kopiera <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> till ditt projekts <file>m4/</file>-katalog.

note: (itstool) path: item/p
en: Add <code>AX_CODE_COVERAGE</code> to <file>configure.ac</file>.
sv: Lägg till <code>AX_CODE_COVERAGE</code> till <file>configure.ac</file>.

note: (itstool) path: section/p
en: Documentation on using gcov and lcov is <link href="http://ltp.sourceforge.net/coverage/lcov.php">here</link>.
sv: Dokumentation för användning av gcov och lcov finns <link href="http://ltp.sourceforge.net/coverage/lcov.php">här</link>.

note: (itstool) path: section/p
en: A full tutorial on using Clang is <link href="http://clang-analyzer.llvm.org/scan-build.html">here</link>.
sv: En fullständig handledning i att använda Clang finns <link href="http://clang-analyzer.llvm.org/scan-build.html">här</link>.

note: (itstool) path: info/desc
en: Designing software to be tested and writing unit tests for it
sv: Designa programvara för testning och skriva enhetstester för den

note: (itstool) path: page/title
en: Unit Testing
sv: Enhetstestning

note: (itstool) path: item/p
en: Write unit tests to be as small as possible, but no smaller. (<link xref="#writing-unit-tests"/>)
sv: Skriv enhetstester så de är så små som möjligt, men inte mindre än så. (<link xref="#writing-unit-tests"/>)

note: (itstool) path: item/p
en: Run all unit tests under Valgrind to check for leaks and other problems. (<link xref="#leak-checking"/>)
sv: Kör alla enhetstester under Valgrind för att söka läckor och andra problem. (<link xref="#leak-checking"/>)

note: (itstool) path: item/p
en: Use appropriate tools to automatically generate unit tests where possible. (<link xref="#test-generation"/>)
sv: Använd lämpliga verktyg för att automatiskt generera enhetstester när det är möjligt. (<link xref="#test-generation"/>)

note: (itstool) path: item/p
en: Design code to be testable from the beginning. (<link xref="#writing-testable-code"/>)
sv: Designa kod så den är testbar från början. (<link xref="#writing-testable-code"/>)

note: (itstool) path: section/title
en: Writing Unit Tests
sv: Skriva enhetstester

note: (itstool) path: section/title
en: Installed Tests
sv: Installerade tester

note: (itstool) path: section/p
en: All unit tests should be installed system-wide, following the <link href="https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests">installed-tests standard</link>.
sv: Alla enhetstester bör installeras systemomfattande, i enlighet med <link href="https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests">standarden installed-tests</link>.

note: (itstool) path: section/p
en: To add support for installed-tests, add the following to <file>configure.ac</file>:
sv: För att lägga till stöd för installed-tests, lägg till följande till <file>configure.ac</file>:

note: (itstool) path: section/p
en: Then in <file>tests/Makefile.am</file>:
sv: Och sedan i <file>tests/Makefile.am</file>:

note: (itstool) path: section/title
en: Test Generation
sv: Testgenerering

note: (itstool) path: section/title
en: Writing Testable Code
sv: Skriva testbar kod

note: (itstool) path: item/p
en: <link href="http://msdn.microsoft.com/en-us/magazine/dd263069.aspx">Design for testability</link>
sv: <link href="http://msdn.microsoft.com/en-us/magazine/dd263069.aspx">Design för testbarhet</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Software_testability">Software testability</link>
sv: <link href="https://en.wikipedia.org/wiki/Software_testability">Testbarhet av programvara</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Dependency_injection">Dependency injection</link>
sv: <link href="https://en.wikipedia.org/wiki/Dependency_injection">Beroendeinjektion</link>

note: (itstool) path: item/p
en: <link href="http://c2.com/cgi/wiki?SoftwareDesignForTesting">Software design for testing</link>
sv: <link href="http://c2.com/cgi/wiki?SoftwareDesignForTesting">Programvarudesign för testning</link>

note: (itstool) path: info/desc
en: Source code version control with git
sv: Versionshantering av källkod med Git

note: (itstool) path: page/title
en: Version Control
sv: Versionshantering

note: (itstool) path: synopsis/p
en: git is used for version control for all GNOME projects. This page assumes good working knowledge of git; some introductory material is available <link href="https://www.atlassian.com/git/tutorials/">here</link>, and a <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">git cheatsheet is here</link>.
sv: git används för versionshantering för alla GNOME-projekt. Denna sida förutsätter god kunskap om git-användning, visst inledande material finns tillgängligt <link href="https://www.atlassian.com/git/tutorials/">här</link>, och en <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">fusklapp för git finns här</link>.

note: (itstool) path: item/p
en: Make atomic, revertable commits. (<link xref="#guidelines-for-making-commits"/>)
sv: Gör odelbara, återställningsbara incheckningar. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Include full reasoning in commit messages, plus links to relevant bug reports or specifications. (<link xref="#guidelines-for-making-commits"/>)
sv: Inkludera ett fullständigt resonemang i incheckningsmeddelanden, samt länkar till relevanta felrapporter eller specifikationer. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Keep large changes, such as renames, in separate commits. (<link xref="#guidelines-for-making-commits"/>)
sv: Håll stora ändringar, så som namnändringar, i separata incheckningar. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: section/title
en: Use of Git
sv: Användning av Git

note: (itstool) path: section/p
en: Most GNOME repositories follow these rules:
sv: De flesta GNOME-arkiven följer dessa regler:

note: (itstool) path: section/title
en: Guidelines for Making Commits
sv: Riktlinjer för att göra incheckningar

note: (itstool) path: item/p
en: Each commit should be written once, and designed to be read many times, by many reviewers and future programmers.
sv: Varje incheckning bör skrivas en gång, och vara designad för att läsas många gånger, av många granskare och framtida programmerare.

note: (itstool) path: section/code
en: 
    git checkout master
    git pull
    
    git checkout wip/<var>my-branch</var>
    git rebase --interactive master
    # Ensure the rebase is successful; test the changes
    
    git checkout master
    git merge wip/<var>my-branch</var>
    git push
    
    # wip/<var>my-branch</var> can now be deleted
    git push origin :wip/<var>my-branch</var>
    git branch -D wip/<var>my-branch</var>
sv: 
    git checkout master
    git pull
    
    git checkout wip/<var>min-gren</var>
    git rebase --interactive master
    # Säkerställ att ombasering lyckades; testa ändringarna
    
    git checkout master
    git merge wip/<var>min-gren</var>
    git push
    
    # wip/<var>min-gren</var> kan nu tas bort
    git push origin :wip/<var>min-gren</var>
    git branch -D wip/<var>min-gren</var>

note: (itstool) path: item/p
en: <link href="https://sethrobertson.github.io/GitBestPractices/">Git best practices</link>
sv: <link href="https://sethrobertson.github.io/GitBestPractices/">Bästa tillvägagångssätt för Git</link>

note: (itstool) path: item/p
en: <link href="https://help.github.com/categories/using-git/">Git FAQ</link>
sv: <link href="https://help.github.com/categories/using-git/">Frågor och svar om Git</link>

note: (itstool) path: item/p
en: <link href="https://www.atlassian.com/git/tutorials/">Atlassian git tutorial</link>
sv: <link href="https://www.atlassian.com/git/tutorials/">Atlassians git-handledning</link>

note: (itstool) path: item/p
en: <link href="http://git-scm.com/docs/gittutorial">Official git tutorial</link>
sv: <link href="http://git-scm.com/docs/gittutorial">Officiell git-handledning</link>

note: (itstool) path: item/p
en: <link href="https://try.github.io/">Interactive git tutorial</link>
sv: <link href="https://try.github.io/">Interaktiv git-handledning</link>

note: (itstool) path: item/p
en: <link href="http://www.git-tower.com/learn/">git-tower tutorial</link>
sv: <link href="http://www.git-tower.com/learn/">Handledning från git-tower</link>

note: (itstool) path: info/desc
en: Versioning and releasing libraries and applications
sv: Versionering och utgåvor av bibliotek och program

note: (itstool) path: synopsis/p
en: Module versioning differs for libraries and applications: libraries need a libtool version specified in addition to their package version. Applications just have a package version.
sv: Versionering för moduler skiljer sig åt för bibliotek och program: bibliotek behöver en libtool-version angiven utöver sin paketversion. Program behöver bara ha en paketversion.

note: (itstool) path: item/p
en: Package versions should be incremented for feature changes or additions. (<link xref="#package-versioning"/>)
sv: Paketversioner bör öka vid funktionsändringar eller tillägg. (<link xref="#package-versioning"/>)

note: (itstool) path: item/p
en: Libtool versions should be updated for API changes or additions. (<link xref="#libtool-versioning"/>)
sv: Libtool-versioner bör uppdateras vid ändringar eller tillägg till API:t. (<link xref="#libtool-versioning"/>)

note: (itstool) path: section/title
en: Package Versioning
sv: Paketversionering

note: (itstool) path: section/title
en: Libtool Versioning
sv: Libtool-versionering

note: (itstool) path: section/p
en: Libraries have two version numbers: a libtool version which tracks ABI backwards compatibility (see <link xref="api-stability"/>), and a package version which tracks feature changes. These are normally incremented in synchronization, but should be kept separate because ABI backwards compatibility is not necessarily related to feature changes or bug fixes. Furthermore, the two version numbers have different semantics, and cannot be automatically generated from each other.
sv: Bibliotek har två versionsnummer: en libtool-version som spårar ABI-bakåtkompatibilitet (se <link xref="api-stability"/>), och en paketversion som spårar funktionsändringar. Dessa ökas vanligen synkroniserat, men bör hållas åtskilda eftersom ABI-bakåtkompatibilitet inte nödvändigtvis är relaterad till funktionsändringar och felkorrigeringar. Vidare har de två versionsnumren olika semantisk mening, och kan inte automatiskt genereras från varandra.

note: (itstool) path: section/p
en: A good overview of libtool versioning, and the differences from package versioning, is given in the <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link>; another is in the <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">libtool manual</link>.
sv: En bra överblick för libtool-versionering, och skillnaderna mot paketversionering ges i <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link>; en annan finns i <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">libtool-handboken</link>.

note: (itstool) path: section/p
en: To update the libtool version, follow the algorithm given in the comments below. This is a typical <file>configure.ac</file> snippet for setting up libtool versioning:
sv: För att uppdatera libtool-versionen, följ algoritmen given i kommentarerna nedan. Detta är en typisk <file>configure.ac</file>-kodsnutt för att konfigurera libtool-versionering:

note: (itstool) path: section/p
en: The following snippet can be used in a <file>Makefile.am</file> to pass that version info to libtool:
sv: Följande kodsnutt kan användas i <file>Makefile.am</file> för att skicka versionsinformationen till libtool:

note: (itstool) path: section/title
en: Stable and Unstable Package Versions
sv: Stabila och instabila paketversioner

note: (itstool) path: section/p
en: The libtool version should be updated only for stable package versions.
sv: libtool-versionen bör endast uppdateras för stabila paketversioner.

note: (itstool) path: section/title
en: Release Process
sv: Utgåveprocess

note: (itstool) path: section/p
en: The release process (based on the <link href="https://wiki.gnome.org/MaintainersCorner/Releasing">GNOME release process</link>):
sv: Utgåveprocessen (baserad på <link href="https://wiki.gnome.org/MaintainersCorner/Releasing">GNOME:s utgåveprocess</link>):

note: (itstool) path: item/p
en: Make sure code is up to date: <cmd>git pull</cmd>
sv: Säkerställ att din kod är à jour: <cmd>git pull</cmd>

note: (itstool) path: item/p
en: Make sure you have no local changes: <cmd>git status</cmd>
sv: Säkerställ att du inte har några lokala ändringar: <cmd>git status</cmd>

note: (itstool) path: item/p
en: If the release is for a stable package version, increment the libtool version number in <file>configure.ac</file> (if it exists)
sv: Om utgåvan är för en stabil paketversion, öka libtool-versionsnumret i <file>configure.ac</file> (om den existerar)

note: (itstool) path: item/p
en: Add an entry to the <file>NEWS</file> file
sv: Lägg till en post i <file>NEWS</file>-filen

note: (itstool) path: item/p
en: Run <cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> and ensure it succeeds
sv: Kör <cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> och säkerställ att det lyckas

note: (itstool) path: item/p
en: Fix any issues which come up, commit those changes, and restart at step 3
sv: Fixa alla problem som dyker upp, checka in ändringarna, och börja om på steg 3

note: (itstool) path: item/p
en: If <cmd>make distcheck</cmd> finishes with “[archive] is ready for distribution”, run <cmd>git commit -a -m "Release version x.y.z"</cmd> (where ‘x.y.z’ is the package version number)
sv: Om <cmd>make distcheck</cmd> avslutar med ”[arkiv] is ready for distribution”, kör <cmd>git commit -a -m "Release version x.y.z"</cmd> (där ”x.y.z” är paketets versionsnummer)

note: (itstool) path: item/p
en: Run <cmd>git push</cmd>
sv: Kör <cmd>git push</cmd>

note: (itstool) path: item/p
en: Tag the release: <cmd>git tag -s x.y.z</cmd> (where ‘x.y.z’ is the package version number)
sv: Tagga utgåvan: <cmd>git tag -s x.y.z</cmd> (där ”x.y.z” är paketets versionsnummer)

note: (itstool) path: item/p
en: Run <cmd>git push origin x.y.z</cmd> (where ‘x.y.z’ is the package version number)
sv: Kör <cmd>git push origin x.y.z</cmd> (där ”x.y.z” är paketets versionsnummer)

note: (itstool) path: section/p
en: The release is now complete, and the post-release version increment can be done:
sv: Utgåvan är nu klar, och versionsökningen efter utgåvans släppande kan göras:

note: (itstool) path: item/p
en: Increment the package version number in <file>configure.ac</file>
sv: Öka paketets versionsnummer i <file>configure.ac</file>

note: (itstool) path: item/p
en: Run <cmd>git commit -a -m "Post-release version increment"</cmd>
sv: Kör <cmd>git commit -a -m "Post-release version increment"</cmd>

note: (itstool) path: section/p
en: The package archive generated by <cmd>make distcheck</cmd> can now be uploaded to download.gnome.org or distributed in other ways.
sv: Paketarkivet som genererats av <cmd>make distcheck</cmd> kan nu skickas till download.gnome.org eller distribueras på andra sätt.

note: (itstool) path: info/desc
en: Good, readable code keeps the project maintainable
sv: Bra, läsbar kod gör att det går att underhålla projektet

note: (itstool) path: page/title
en: The Importance of Writing Good Code
sv: Vikten av att skriva bra kod

note: (itstool) path: page/p
en: GNOME is a very ambitious free software project, and it is composed of many software packages that are more or less independent of each other. A lot of the work in GNOME is done by volunteers: although there are many people working on GNOME full-time or part-time for here, volunteers still make up a large percentage of our contributors. Programmers may come and go at any time and they will be able to dedicate different amounts of time to the GNOME project. People’s “real world” responsibilities may change, and this will be reflected in the amount of time that they can devote to GNOME.
sv: GNOME är ett väldigt ambitiöst projekt inom fri programvara, och består av många programvarupaket som är mer eller mindre oberoende av varandra. En stor del av arbetet i GNOME utförs av frivilliga: även om det finns många som arbetar med GNOME som ett heltids- eller deltidsjobb, så är frivilliga fortfarande en stor andel av våra bidragsgivare. Programmerare kan komma och gå när som helst, och de kommer kunna ägna olika mängder tid till GNOME-projektet. Det ansvar folk har i ”verkliga livet” kan ändras, och detta kommer reflekteras i hur mycket tid de kan lägga ner på GNOME.

note: (itstool) path: page/p
en: Software development takes long amounts of time and painstaking effort. This is why most part-time volunteers cannot start big projects by themselves; it is much easier and more rewarding to contribute to existing projects, as this yields results that are immediately visible and usable.
sv: Programvaruutveckling tar mycket tid och stor möda i anspråk. Detta är orsaken till att de flesta deltidsfrivilliga inte kan starta stora projekt på egen hand; det är mycket enklare och mer belönande att bidra till befintliga projekt, då detta ger resultat som omedelbart är synliga och användbara.

note: (itstool) path: page/p
en: Thus, we conclude that it is very important for existing projects to make it as easy as possible for people to contribute to them. One way of doing this is by making sure that programs are easy to read, understand, modify, and maintain.
sv: Vi kan därför dra slutsatsen att det är mycket viktigt för befintliga projekt att göra det så enkelt som möjligt för folk att bidra till dem. Ett sätt att göra detta är genom att säkerställa att program är lätta att läsa, förstå, modifiera och underhålla.

note: (itstool) path: page/p
en: Messy code is hard to read, and people may lose interest if they cannot decipher what the code tries to do. Also, it is important that programmers be able to understand the code quickly so that they can start contributing with bug fixes and enhancements in a short amount of time. Source code is a form of <em>communication</em>, and it is more for people than for computers. Just as someone would not like to read a novel with spelling errors, bad grammar, and sloppy punctuation, programmers should strive to write good code that is easy to understand and modify by others.
sv: Rörig kod är svårläst, och folk kan tappa intresset om de inte kan tolka vad koden försöker göra. Det är också viktigt att programmerare kan förstå koden snabbt så att de på kort tid kan börja bidra med felkorrigeringar och förbättringar. Källkod är en sorts <em>kommunikation</em>, och det är mer för människor än för datorer. Precis som få personer skulle vilja läsa en roman med stavfel, dålig grammatik och slarvig användning av skiljetecken, så bör programmerare sträva efter att skriva bra kod som är lätt att förstå och modifiera för andra.

note: (itstool) path: page/p
en: The following are some important qualities of good code:
sv: Följande är några viktiga kvaliteter hos bra kod:

note: (itstool) path: item/title
en: Cleanliness
sv: Renhet

note: (itstool) path: item/p
en: Clean code is easy to read with minimum effort. This lets people start to understand it easily. This includes the coding style itself (brace placement, indentation, variable names), and the actual control flow of the code.
sv: Ren kod är enkel att läsa med minimal ansträngning. Detta låter folk börja förstå den lätt. Detta inkluderar både kodstilen själv (parentesplacering, indentering, variabelnamn) och kodens faktiska kontrollflöde.

note: (itstool) path: item/title
en: Consistency
sv: Konsekvens

note: (itstool) path: item/p
en: Consistent code makes it easy for people to understand how a program works. When reading consistent code, one subconsciously forms a number of assumptions and expectations about how the code works, so it is easier and safer to make modifications to it. Code that <em>looks</em> the same in two places should <em>work</em> the same, too.
sv: Konsekvent kod gör det lätt för folk att förstå hur ett program fungerar. Då man läser konsekvent kod formar man undermedvetet ett antal antaganden och förväntningar på hur koden fungerar, så det är lättare och säkrare att göra ändringar i den. Kod som <em>ser ut</em> på samma sätt på två ställen bör också <em>fungera</em> på samma sätt.

note: (itstool) path: item/title
en: Extensibility
sv: Utökningsbarhet

note: (itstool) path: item/p
en: General-purpose code is easier to reuse and modify than very specific code with lots of hardcoded assumptions. When someone wants to add a new feature to a program, it will obviously be easier to do so if the code was designed to be extensible from the beginning. Code that was not written this way may lead people into having to implement ugly hacks to add features.
sv: Kod för allmänna syften är lättare att återanvända och modifiera än väldigt specifik kod med många hårdkodade antaganden. Då någon vill lägga till ny funktionalitet till ett program kommer det uppenbart vara lättare att göra detta om koden från början designats för att vara utökningsbar. Kod som inte har skrivits på detta sätt kan leda folk till att behöva implementera fula hack för att lägga till funktionalitet.

note: (itstool) path: item/title
en: Correctness
sv: Korrekthet

note: (itstool) path: item/p
en: Finally, code that is designed to be correct lets people spend less time worrying about bugs, and more time enhancing the features of a program. Users also appreciate correct code, since nobody likes software that crashes. Code that is written for correctness and safety (i.e. code that explicitly tries to ensure that the program remains in a consistent state) prevents many kinds of silly bugs.
sv: Slutligen låter kod som designats för att vara korrekt folk spendera mindre tid på att oroa sig om fel, och mer tid på att förbättra ett programs funktioner. Användare uppskattar korrekt kod, eftersom ingen tycker om programvara som kraschar. Kod som skrivits för korrekthet och säkerhet (d.v.s. kod som explicit försöker försäkra sig om att programmet förblir i ett konsekvent tillstånd) förhindrar många sorters fåniga fel.

note: (itstool) path: section/title
en: Book References
sv: Bokreferenser

note: (itstool) path: item/p
en: <link href="http://www.cc2e.com">Code Complete</link>, by Steve McConnell.
sv: <link href="http://www.cc2e.com">Code Complete</link>, av Steve McConnell.

note: (itstool) path: item/p
en: <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, by Martin Fowler.
sv: <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, av Martin Fowler.

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software </link>, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
sv: <link href="https://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software</link>, av Erich Gamma, Richard Helm, Ralph Johnson och John Vlissides.

note: (itstool) path: item/p
en: <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link>, by Arthur Riel.
sv: <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics</link>, av Arthur Riel.
