Localization/Concepts/PO Odyssey (fi) - Revision history

AnneW at 13:52, 18 July 2012

2012-07-18T13:52:01Z

Neverendingo: Text replace - "`" to ""`


2011-06-29T21:09:16Z
Text replace - "<code po>" to "<syntaxhighlight lang="text">"
Show changes



Neverendingo: Text replace - "" to ""

2011-06-29T21:00:05Z
Text replace - "<code cpp>" to "<syntaxhighlight lang="cpp">"

				
				
				
				
			
			← Older revision
			Revision as of 21:00, 29 June 2011
			
Line 105:
Line 105:
  is of that kind. Then, by following the source reference, you see this statement in the file <tt>addcatdialog.cpp</tt>, line 45:   is of that kind. Then, by following the source reference, you see this statement in the file <tt>addcatdialog.cpp</tt>, line 45:
    
− <code cpp> + <syntaxhighlight lang="cpp">
  setCaption( i18n( "Import Catalog" ) );   setCaption( i18n( "Import Catalog" ) );
  </syntaxhighlight>   </syntaxhighlight>



Neverendingo: Text replace - "" to ""
2011-06-29T20:57:21Z
Text replace - "</code>" to "</syntaxhighlight>"
Show changes


Neverendingo: Text replace - "" to ""

2011-06-29T20:48:00Z
Text replace - "<code>" to "<syntaxhighlight lang="text">"

				
				
				
				
			
			← Older revision
			Revision as of 20:48, 29 June 2011
			
Line 651:
Line 651:
  But, how should the application know which form corresponds to which numbers? The specification for this is written within the PO file itself, in the ''header'' (more on PO headers [[#PO Header|below]]); it consists of the number of plural forms which every plural message in the given PO file shall have, and a computable logical expression, which for any given number, computes the index of the plural form to be used. This expression is quite cryptic-looking, but you do not have to really understand how it works. Since it is constant for a given language, you can just copy it from any other previously translated PO file in your language, and by looking at plural messages in that other file, you will clearly see which form (by index of <tt>msgstr</tt>) is used in which situation. Bearing this in mind, just to complete the examples, here is the plural specification for Spanish:   But, how should the application know which form corresponds to which numbers? The specification for this is written within the PO file itself, in the ''header'' (more on PO headers [[#PO Header|below]]); it consists of the number of plural forms which every plural message in the given PO file shall have, and a computable logical expression, which for any given number, computes the index of the plural form to be used. This expression is quite cryptic-looking, but you do not have to really understand how it works. Since it is constant for a given language, you can just copy it from any other previously translated PO file in your language, and by looking at plural messages in that other file, you will clearly see which form (by index of <tt>msgstr</tt>) is used in which situation. Bearing this in mind, just to complete the examples, here is the plural specification for Spanish:
    
− <code> + <syntaxhighlight lang="text">
  nplurals=2; plural=n != 1;   nplurals=2; plural=n != 1;
  </code>   </code>
Line 657:
Line 657:
  and for the more complicated Polish plural:   and for the more complicated Polish plural:
    
− <code> + <syntaxhighlight lang="text">
  nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);   nplurals=3; plural=(n==1 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);
  </code>   </code>



Centerlink: Still translating part of text.
2009-10-30T09:42:45Z
Still translating part of text.

				
				
				
				
			
			← Older revision
			Revision as of 09:42, 30 October 2009
			
Line 21:
Line 21:
  Siisti ja yksinkertainen, kaikki ovat onnellisia? Väärin (arvasit sen). Tämä putki on, tarkoituksellisesti, sellainen, jota useimmat ihmiset tuntuvat kuvittelevan ennen kuin todella perehtyvät paikallistamiseen. Mutta ennen kuin selitän miksi se on väärin, ja siksi sitä ei ollenkaan käytetä vapaan ohjelmiston paikallistamisessa, siirrytään vielä hypoteettisemmälle maaperälle.   Siisti ja yksinkertainen, kaikki ovat onnellisia? Väärin (arvasit sen). Tämä putki on, tarkoituksellisesti, sellainen, jota useimmat ihmiset tuntuvat kuvittelevan ennen kuin todella perehtyvät paikallistamiseen. Mutta ennen kuin selitän miksi se on väärin, ja siksi sitä ei ollenkaan käytetä vapaan ohjelmiston paikallistamisessa, siirrytään vielä hypoteettisemmälle maaperälle.
    
− The previous example was about ''static'' translation, such as of a text document or an HTML page. While the example pipeline was not appropriate, even with the proper pipeline the output for the end user must be a static translated document, such as PDF file or another HTML page. How does this map onto a translated user interface in an application, which has live code running in the background? For starters, we can be unimaginative and follow the static route: the programmer may keep all the user interface text strings in a text file, which gets built into the application executable files when the installation package is built. Following the same poor pipeline, the translator may translate that text file, replacing string after string, after which another installation package is built, this time a localized one. So, like in the case of PDF files, where in the end there must be one per language, there would also be one application package for each language. + Edellinen esimerkki oli ''staattinen'' paikallistaminen, kuten dokumenttitekstinä tai HTML-sivuna. Samalla kun esimerkkiputki ei ollut tarkoituksenmukainen, vaikkakin jopa oikeassa putkessa tulosteen loppukäyttäjälle täytyy olla staattisesti paikallistettu dokumentti, kuten PDF-tiedosto tai toinen HTML-sivu. Kuinka se sopii yhteen sovelluksen paikallistetun käyttöliittymän kanssa, koska siinä elävää koodia toimii taustalla? Aluksi voimme olla mielikuvituksettomia ja seurata staattista reittiä: ohjelmoija voi pitää kaikki käyttöliittymän merkkijonot tekstitiedostossa, joka rakennetaan suoritettavaan sovellustiedostoon kun asennuspakkaus rakennetaan. Seuraten samaa surkeaa putkea paikallistaja paikallistaa tekstitiedoston, korvaten merkkijonon merkkijonolta, minkä jälkeen rakennetaan toinen asennuspakkaus, tällä kertaa paikallistettu. Joten kuten PDF-tiedoston tapauksessa, jossa lopussa oli yksi jokaiselle kielelle, olisi myös yksi sovelluspakkaus jokaiselle kielelle.
    
  However, the bulk of a PDF file is the text itself, so there is almost no needless duplication of language-independent content. On the contrary, in an average application, like a file manager or a web browser, the translatable text is a minuscule part of the total size of installation package. Thus, having one package per language would make for a paramount waste of digital space. If we imagine a typical operating system distribution these days, this would pretty much prevent default installation disks from carrying anything but original English packages. Suffices to say, static translation of applications is hardly an option with free software, which makes international reach one of its primary goals.   However, the bulk of a PDF file is the text itself, so there is almost no needless duplication of language-independent content. On the contrary, in an average application, like a file manager or a web browser, the translatable text is a minuscule part of the total size of installation package. Thus, having one package per language would make for a paramount waste of digital space. If we imagine a typical operating system distribution these days, this would pretty much prevent default installation disks from carrying anything but original English packages. Suffices to say, static translation of applications is hardly an option with free software, which makes international reach one of its primary goals.



Centerlink: Still translating part of text.
2009-10-30T08:39:34Z
Still translating part of text.

				
				
				
				
			
			← Older revision
			Revision as of 08:39, 30 October 2009
			
Line 19:
Line 19:
  * käyttäjä saa luettavakseen paikallistetun dokumentin PDF-muodossa Writer-ohjelman tulosteena.   * käyttäjä saa luettavakseen paikallistetun dokumentin PDF-muodossa Writer-ohjelman tulosteena.
    
− Clean and simple, everyone is happy, right? Wrong (you guessed it). This pipeline is, incidentally, the one which most people seem to imagine before they get involved in localization for real. But before explaining why it is wrong, and therefore not at all used in free software translation, let us cover more hypothetical ground. + Siisti ja yksinkertainen, kaikki ovat onnellisia? Väärin (arvasit sen). Tämä putki on, tarkoituksellisesti, sellainen, jota useimmat ihmiset tuntuvat kuvittelevan ennen kuin todella perehtyvät paikallistamiseen. Mutta ennen kuin selitän miksi se on väärin, ja siksi sitä ei ollenkaan käytetä vapaan ohjelmiston paikallistamisessa, siirrytään vielä hypoteettisemmälle maaperälle.
    
  The previous example was about ''static'' translation, such as of a text document or an HTML page. While the example pipeline was not appropriate, even with the proper pipeline the output for the end user must be a static translated document, such as PDF file or another HTML page. How does this map onto a translated user interface in an application, which has live code running in the background? For starters, we can be unimaginative and follow the static route: the programmer may keep all the user interface text strings in a text file, which gets built into the application executable files when the installation package is built. Following the same poor pipeline, the translator may translate that text file, replacing string after string, after which another installation package is built, this time a localized one. So, like in the case of PDF files, where in the end there must be one per language, there would also be one application package for each language.   The previous example was about ''static'' translation, such as of a text document or an HTML page. While the example pipeline was not appropriate, even with the proper pipeline the output for the end user must be a static translated document, such as PDF file or another HTML page. How does this map onto a translated user interface in an application, which has live code running in the background? For starters, we can be unimaginative and follow the static route: the programmer may keep all the user interface text strings in a text file, which gets built into the application executable files when the installation package is built. Following the same poor pipeline, the translator may translate that text file, replacing string after string, after which another installation package is built, this time a localized one. So, like in the case of PDF files, where in the end there must be one per language, there would also be one application package for each language.



Centerlink: Still translating part of text.
2009-10-30T08:05:15Z
Still translating part of text.

				
				
				
				
			
			← Older revision
			Revision as of 08:05, 30 October 2009
			
Line 2:
Line 2:
    
  {{LocalizationBrowser|   {{LocalizationBrowser|
− section=[[Localization#Concepts|Concepts]]| + section=[[Localization#Concepts|Konseptit]]|
  name=The PO Format|   name=The PO Format|
− prereqs=[[Localization/Concepts/Text Encoding|Text Encoding]]| + prereqs=[[Localization/Concepts/Text Encoding|Tekstikoodaukset]]|
− related=[[Localization/Concepts/XML_Markup|XML Markup]], [[Localization/Concepts/Gettext_Tools|Gettext Tools]]| + related=[[Localization/Concepts/XML_Markup|XML Markup-kieli]], [[Localization/Concepts/Gettext_Tools|Gettext-työkalut]]|
− extread=[http://www.gnu.org/software/gettext/manual/gettext.html Gettext Manual]| + extread=[http://www.gnu.org/software/gettext/manual/gettext.html Gettext-käsikirja]|
  }}   }}
    
  == Paikallistamisten asettaminen paikalleen ==   == Paikallistamisten asettaminen paikalleen ==
    
− Before going into technical details of the PO (or any other) format, it is useful to examine the conceptual ways in which the text can flow from the author, through the translator, and to the user. Let us call this chain the ''translation pipeline'', and consider the following example of it: + Ennen kuin menemme PO-muodon (tai minkään muunkaan muodon) teknisiin yksityiskohtiin, on hyödyllistä tutkia konseptitasolla niitä tapoja, joilla teksti virtaa tekijältä paikallistajan kautta käyttäjälle. Kutsukaamme tätä ketjua ''paikallistamisputkeksi" ja tarkastellaan seuraavaa esimerkkiä siitä:
    
− * the author prepares a text document, say, in OpenOffice Writer; + * tekijä valmistaa tekstidokumentin, sanotaan vaikka OpenOffice Writer-ohjelmassa;
    
− * the translator gets that document, and translates it also in Writer, by replacing original for translated text paragraph by paragraph; + * paikallistaja hakee dokumentin ja paikallistaa sen myös Writer-ohjelmassa korvaamalla alkuperäistekstin paikallistetulla tekstillä kappale kappaleelta;
    
− * the user gets to read the translated document, in PDF, as output by Writer. + * käyttäjä saa luettavakseen paikallistetun dokumentin PDF-muodossa Writer-ohjelman tulosteena.
    
  Clean and simple, everyone is happy, right? Wrong (you guessed it). This pipeline is, incidentally, the one which most people seem to imagine before they get involved in localization for real. But before explaining why it is wrong, and therefore not at all used in free software translation, let us cover more hypothetical ground.   Clean and simple, everyone is happy, right? Wrong (you guessed it). This pipeline is, incidentally, the one which most people seem to imagine before they get involved in localization for real. But before explaining why it is wrong, and therefore not at all used in free software translation, let us cover more hypothetical ground.



Centerlink: Preliminary and still partly Finnish translation.
2009-10-30T07:52:18Z
Preliminary and still partly Finnish translation.
Show changes

← Older revision		Revision as of 13:52, 18 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Localization/Concepts/PO_Odyssey}}~~

	{{LocalizationBrowser\|		{{LocalizationBrowser\|