Poll: How do you want to manage pcsx2_Iconized.pot?
You do not have permission to vote in this poll.
Use standard approach, pot contains directly the string to translate
100.00%
9 100.00%
Keep key which must be lookup in the source code
0%
0 0%
Total 9 vote(s) 100%
* You voted for this item. [Show Results]

[poll] Translation => pcsx2_Iconized.pot
#1
Hello Dev, Translator.

As you already maybe aware, current pcsx2_Iconized.pot doesn't contain directly the string to translate instead a "key" that must be lookup into the code source. See the reason below.
Quote:The gettext system has many conveniences over other methods of internationalization, which typically rely on the use of pre-processor macros or dynamically linked functions that return string values. The main drawback is that this method relies on the exact English representation, including punctuation, which means that even the slightest change to a text string in PCSX2 will break the translation for that string. For most short messages, such as menu items and button labels, this is fine and is in fact desirable behavior. But for longer messages that serve as descriptions of actions or checkbox options, some of which include formating to fit them to the dialog box more neatly, it can be problematic. This is why PCSX2 has an extension to gettext that uses iconized string matching instead ot the usual literal string matching.

choice 1/ Keep current extension for iconized:
+ don't need to change for little change
- can potentially mask big change if a dev doesn't recreate a new key
- Add difficulty for translator which need to get PCSX2 code source and understand how to lookup the string

choice 2/ Use a more standard approach for Iconized
- need update for every little modification
+ translators don't need to bother with PCSX2 code source

Discussion is now taking place. Opinion are welcomes.

Note: outcome decision will impact PCSX2 1.1.0 and later not current 0.9.0(svn) /1.0.0 (branch)
Reply

Sponsored links

#2
I vote for choice 2 (standard approach).

Poedit, provided for both Windows and Linux, recognizes that a new string matches with old that is kept commented in the end of the po file. Then, it will suggest the matched string in "fuzzy" state. So, if developers make a little change, translator doesn't have to do it all over again, just need to fix the 'fuzzied' string.

Not having to go look in the source code for the string makes it much faster to translate. No need to switch windows, but just go down to next string and translate - piece of cake.
Reply
#3
I vote for standard Approach. Its difficult to lookup the source code everytime. Its better if the Poedit contained the Actual String to be translated.

Bengali Translation GUI :- 30% Done (will post soon Tongue2)
[Image: recodersignature2.png]
Reply
#4
I vote for Standard approach too...

Reason: same as those who already posted
Reply
#5
I think standard approach is best as well
[Image: newsig.jpg]
Reply
#6
I vote for standard approach too. It would be a lot easier for translators.
Reply
#7
Standard approach is easier.

A little proposal: you should create a page (or enhance the existing) on googlecode wiki detailing how to update translation strings directly from Poedit after a SVN Checkout done with Tortoise SVN (something I've done and found pretty handy).
Λευκος
SStateMan - a savestate managing tool for PCSX2
Currently playing:
- PS2 -> PCSX2: Stella Deus
- PC : Skyrim
Reply
#8
(06-06-2012, 08:49 PM)Leucos Wrote: A little proposal: you should create a page (or enhance the existing) on googlecode wiki detailing how to update translation strings directly from Poedit after a SVN Checkout done with Tortoise SVN (something I've done and found pretty handy).

But when you change the po file inside the SVN directory, you won't be able to do a 'svn update' later unless you reverse the changes (or am I wrong?).

That's how I translate: I do svn checkout and copy my PO file to outside the svn directory, and then update PO using POT catalog or using keywords in source code. Then translate.
Reply
#9
(06-06-2012, 10:04 PM)josephg Wrote: But when you change the po file inside the SVN directory, you won't be able to do a 'svn update' later unless you reverse the changes (or am I wrong?).

That's how I translate: I do svn checkout and copy my PO file to outside the svn directory, and then update PO using POT catalog or using keywords in source code. Then translate.

Yes, it's the same thing I do.
But after copying the po files in a new directory I also change the catalogs base path in poedit so that I can still use the 'Update from sources' command (and others).

Here it is an example of what I've done:
- I use two folders in the same place, folder#1 contains the copy of the po files I work on, folder#2 is where I do the svn checkout of the trunk/branch.
- I opened the po files in folder#1 in poedit and opened "Catalog" > "Settings...", "Paths" tab.
- In the "Base path" I've set "..\[folder#2 name]", so that poedit will go up of one level (parent directory of both folder#1 and folder#2) and then enter folder#2 (where the sources are).
- After setting this you can use "Catalog" > "Update from sources" or the third button in the toolbar.
Changing this settings should not break anything (finger crossed).
I hope this little explanation is clear as I'm not that great at explaining things in general.
Λευκος
SStateMan - a savestate managing tool for PCSX2
Currently playing:
- PS2 -> PCSX2: Stella Deus
- PC : Skyrim
Reply




Users browsing this thread: 1 Guest(s)