31
Translations / Re: Translator feedback required
« on: November 22, 2012, 05:54:35 pm »
Thank you, now Hungarian support is also in my PR.
Welcome, Guest. Please login or register.
Did you miss your activation email? January 25, 2025, 10:23:35 pm
Did you miss your activation email? January 25, 2025, 10:23:35 pm
News: If you can't login, please contact us with your username and e-mail so we can fix it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
32
Translations / Re: Translator feedback required
« on: November 22, 2012, 03:58:54 pm »
That's the idea, although the code side is closer to Qt's QTranslator.
Too bad gettext requires LOTS of additional libraries in Windows...
Too bad gettext requires LOTS of additional libraries in Windows...
33
Work In Progress / Re: New weapon graphics
« on: November 22, 2012, 03:52:42 pm »
Just wait until we hit 1.0! Then the gates will open...
34
Translations / Re: Translator feedback required
« on: November 22, 2012, 03:03:25 pm »If that's it, then it's in Hungarian:If you have alma and almák, then it's not all singular, is it?
They are all the same, SINGULAR:
0 alma.
1 alma.
2 alma.
(alma=apple, almák=apples)
I don't want the actual words, I want the different cases, as in "Sentences (nouns, verbs, whatever) will take one of X forms, where form 1 is for value A-B, form 2 for values C-F", etc.
BTW, why do you even bother with every language on your own?
Why not just modify the language files, appending with the thing, and let the translators "fix" the strings? (and they send it within a PR)
The thing requires coding support, because I implement it with looking for differently suffixed key (eg STR_1, STR_2). So I need to know how many keys, and when to use the proper suffix. Then I'll be done with basic coding support, and the hard work of replacing fragment sentence assembly with proper placeholders will begin.
Hopefully, the basic support will be accepted upstream, and we'll change the texts incrementally, perhaps after proding by translators for the worst examples (eg see post about laser rifle manufacture).
35
Programming / Re: Implemented: Funding nations and activity scores
« on: November 22, 2012, 10:57:39 am »
Just two coding observations:
- Prefer ++var over var++, unless the code will behave differently.
- You don't need to use .c_str() when sending std::wstring to streams (ie in you reporting function).
36
Translations / Re: Translator feedback required
« on: November 22, 2012, 09:51:33 am »
No, something more basic.
It's better to use an example:
In English, Greek and French, words can be either singular (1 of something) or plural (more than one).
English and Greek use plural for 0 as well, French uses singular.
So:
English, Greek: 2 forms, n == 1, n !=1
French: 2 forms, n < 2, n >1
So English and Greek language files would contain id strings with suffixes _0 (optional, used when n == 0), _1 (required, used when n == 1), _2 (required, used when n != 1) in the language file, while French would _0 (optional, used when n == 0), _1 (required, used when n < 2), _2 (required, used when n > 1).
What I want is exactly these rules for other languages.
It's better to use an example:
In English, Greek and French, words can be either singular (1 of something) or plural (more than one).
English and Greek use plural for 0 as well, French uses singular.
So:
English, Greek: 2 forms, n == 1, n !=1
French: 2 forms, n < 2, n >1
So English and Greek language files would contain id strings with suffixes _0 (optional, used when n == 0), _1 (required, used when n == 1), _2 (required, used when n != 1) in the language file, while French would _0 (optional, used when n == 0), _1 (required, used when n < 2), _2 (required, used when n > 1).
What I want is exactly these rules for other languages.
37
Translations / Re: Linguistics and style discussion station
« on: November 22, 2012, 08:38:06 am »
Generally, preparing a program for localization means avoiding assembling sentences in code, making the whole sentence available for the transators.
As a native Greek speaker I can only envy English programmers that can do assembling so easy, but localization is where is comes back to bite us.
As a native Greek speaker I can only envy English programmers that can do assembling so easy, but localization is where is comes back to bite us.
38
Translations / Translator feedback required
« on: November 22, 2012, 08:20:24 am »
I am attempting to create a more language-agnostic OpenXcom, by making more full sentences part of the language strings instead of building them from parts.
In the process string markers will be used, as well as plural forms.
So you have IDs like (for plural forms):
And argument substitution:
Plural forms CAN be combined with argument substitution, but only like this:
The plural forms work for 0 (_0) and for language specific cases.
If the 0 case is not found, the language rules (eg plural for English, singular for French) are used.
Can the translators (or other speakers) please provide me with the different cases (number of forms and the numbers they refer to, not actual text needed)?
I currently have the rules for:
All other languages (now) use the English rules.
In the process string markers will be used, as well as plural forms.
So you have IDs like (for plural forms):
Code: [Select]
STR_DAYS_LEFT_0
No days left.
STR_DAYS_LEFT_1
Just {N} day left.
STR_DAYS_LEFT_2
Only {N} days left.
And argument substitution:
Code: [Select]
https://Engilsh (US)
STR_FAKE_craftweapon_MESSAGE_crafttype_EXAMPLE
This is a {1} for {2}.
https://Engilsh (UK)
STR_FAKE_craftweapon_MESSAGE_crafttype_EXAMPLE
Only {2} can use {1}.
Plural forms CAN be combined with argument substitution, but only like this:
Code: [Select]
STR_FAKE_crafttype_WARNING_0
No {1} in base
STR_FAKE_crafttype_WARNING_1
{N} {1} left in base
STR_FAKE_crafttype_WARNING_2
{1} in base: {N}
The plural forms work for 0 (_0) and for language specific cases.
If the 0 case is not found, the language rules (eg plural for English, singular for French) are used.
Can the translators (or other speakers) please provide me with the different cases (number of forms and the numbers they refer to, not actual text needed)?
I currently have the rules for:
- Czech
- English
- French
- Hungarian
- Polish
- Romanian
- Rusian
All other languages (now) use the English rules.
39
Programming / Re: Questions about code / design decisions
« on: November 22, 2012, 07:43:51 am »
No, it just bloats the repository. 
The proper (tm) way to do this would be to have seperate repositories for each library and use git submodules. Which are not familiar to many people.
The proper (tm) way to do this would be to have seperate repositories for each library and use git submodules. Which are not familiar to many people.
40
Programming / Re: Questions about code / design decisions
« on: November 22, 2012, 07:32:00 am »
Re: The engine-state-extension fiasco: 
Re: Pulling in all external libraries:
I am deeply opposed but that may be because working in Linux getting them is easy.
Re: libyaml
It appears to be extremely low level. One would essentially rewrite YAML-cpp if one tries to make it OOP, or at least that's what I can see from the API in the wiki.
Re: Pulling in all external libraries:
I am deeply opposed but that may be because working in Linux getting them is easy.
Re: libyaml
It appears to be extremely low level. One would essentially rewrite YAML-cpp if one tries to make it OOP, or at least that's what I can see from the API in the wiki.
41
Programming / Re: Refactoring translation
« on: November 21, 2012, 06:50:48 pm »
I have turned it into a regular pull request, awaiting review and approval.
Most of the code is trivial changes:
Most of the real changes are in LocalizedText, which avoids string copy as long as possible.
And I have also changed the code to output 'N day(s)' and 'Not enough _ammo_ to equip HWP.' as example / test of the new LocalizedText API.
Most of the code is trivial changes:
- Changed _game->getLanguage()->getString to tr if called in a State-derived class.
- String addition is not supported, use streaming instead.
Most of the real changes are in LocalizedText, which avoids string copy as long as possible.
And I have also changed the code to output 'N day(s)' and 'Not enough _ammo_ to equip HWP.' as example / test of the new LocalizedText API.
42
Programming / Re: Refactoring translation
« on: November 21, 2012, 01:01:55 pm »
Ok, I have a few questions to ask the main developers:
Obviously, if gettext is acceptable, then (2) and (4) become moot.
- Is it acceptable to just move the translation stuff over to gettext? I mean, if I do the work, is it ever going to get merged
- In Language::loadLng(), why are we not using std::getline(stream, string) and we read character by character? Was there a proper reason or just inertia?
- I'm assuming Language::toHtml() is just old and rusted code, and safe to remove. No one is calling it. Do we want to keep it?
- How much leeway is there in the Language file format? For now I have specific suffixes (_0 ... _3) and extra tags ({ALT}, {1} ... {N}).
Obviously, if gettext is acceptable, then (2) and (4) become moot.
43
Programming / Re: [IMPORTANT] How to contribute code
« on: November 21, 2012, 01:22:03 am »
Another think to know / use:
When making git commits, the first line should be short (up to 50 characters), and be a meaning full description/title.
The next line should be empty.
This way the git history looks much nicer.
When making git commits, the first line should be short (up to 50 characters), and be a meaning full description/title.
The next line should be empty.
This way the git history looks much nicer.
44
Programming / Re: Refactoring translation
« on: November 20, 2012, 02:28:30 pm »
I decided against doing a singleton, and modifying Language instead, so no nice macros, until Supsuper allows globals!
On the other hand, most of the code will remain the same, only the cases with arguments will (eventually) change.
On the other hand, most of the code will remain the same, only the cases with arguments will (eventually) change.
45
Programming / Re: Refactoring translation
« on: November 20, 2012, 01:37:25 pm »
The translation system I propose is based upon the API for Qt translation, although modified to use IDs instead of default strings. So, although the translation code will change, the language file can be kept with minor changes.
I now have code that compiles but is never used. Once I have replaced the old API in a few places, I'll post an update, so people can review the new system.
I now have code that compiles but is never used. Once I have replaced the old API in a few places, I'll post an update, so people can review the new system.