Hi Michael, Thanks for taking time to write down these questions and prepare the examples. Zibi already suggested a possible solution. I'd like to go on a tangent in my response.
On Sun, May 10, 2015 at 12:51 AM, Michael Wolf <[email protected]> wrote: > Is it possible to distinguish personality/impoersonality > instead of gender in l20n? I saw that there is a value "unknown" for > gender. Can this value be "abused" to express personality? > […] > It is about personality as well. With nouns, personality/impersonality > exists as well: Personal forms exist for male persons in nominative and > accusative dual and plural only. Besides there is the category animacy > resp. animated gender - animated subjects have the ending of the > genitive in accusative, inanimated subjects the ending of the > nominative. Animated gender exists in singular only. > As a native Polish speaker I can relate to your questions and in fact I've wondered about these things a lot. While I enjoy testing the L20n syntax and proving things possible, I noticed that often times it is important to remember where the data is coming from. The are two possible sources of data and each has different implications for your questions: 1. other entities in the localizations, 2. variables passed in by the developer. In the case of other entities, #1, you are free to add any number of grammatical attributes to entities. You can thus have: <father "Nan" _gender: "masculine" _animacy: "animate" _personality: "person"> The underscore denote a "local" attribute, i.e. an attribute which is only specific to your language. Other translations aren't required to have them. You can then use these attributes in macros and other entities: <drank[father::_gender] { masculine: "{{ father }} pił", feminine: "{{ father }} piła" }> This will select the right translation based on the value of father's _gender attribute. But wait, this doesn't look right at all. We're hardcoding father anyways and there is no room for varying translations, since father's gender is always masculine! It's tempting to think of L20n as a tool to describe grammatical intricacies of a language; we'd then arrive at a situation where all nouns have their own entities and are properly marked up with grammatical attributes. But perhaps a better way to think of L20n is to view it as a tool for translating interfaces which doesn't require a systemic approach to all of grammar. In the example above we're hardcoding "father" anyways, so the following would be better and simpler: <drank "{{father}} pił"> Or even: <drank "Nan pił"> Now, there are cases when it's helpful to abstract a piece of translation into its own entity. Suppose we want to have a generic entity called "parent" and in some builds we want it to be "father" and in some, "mother." This is not unlike what we do in Mozilla when we choose between the official and unofficial branding but let's stick to our family examples. In one build we can define: <parent "Nan" _gender: "masculine" _animacy: "animate" _personality: "person"> And in another: <parent "Mama" _gender: "feminine" _animacy: "animate" _personality: "person"> In both we define the following translation: <drank[parent::_gender] { masculine: "{{ parent }} pił", feminine: "{{ parent }} piła" }> This makes much more sense now and you can hopefully see that you can use all grammatical attributes as needed to make this work. But keep in mind that you also don't need to do this for all nouns in your translations. You probably don't have to define separate entities for "tab", "button", "widow", "menu" and tons of others because it's just easier to type that in verbatim, if it doesn't change. * * * On to the data passed into the localization by the developer, or app. These are all the things that are external to the localization,like usernames or number of unread messages etc. In this case you have to rely on developer doing the right thing: Translation: <sent "{{ $name }} sent you a message."> Code: l20n.formatValue('sent', { name: Users.get(..) }); This is bad code because some localizations might need more information about the user than just the name. For instance, you might want the gender of the user to be passed, but you should also prepare for the case when it's not available (the user might have declined to give that info to the app). An example in Polish: <sent[$user.gender] { masculine: "{{ $user.name }} wysłał ci wiadomość.", faminine: "{{ $user.name }} wysłała ci wiadomość.", *unknown: "Uzytkownik {{ $user.name }} wysłał ci wiadomość." }> Back to your questions, to make this work for Upper and Lower Sorbian, you'd need to ask developer to pass the required bits of information about the subjects and objects in the translations. For instance, if the message is one of: "Flag this user" (masculine animate) or "Flag this image" (masculine inanimate) you technically could create a single entity in L20n which caters to all those objects: <flag[$object.animacy] { animate: "Zgłoś tego użytkownika", inanimate: "Zgłoś ten obraz" }> But again, we're hardcoding the "user" and the "image" in the translation and it's not that easy to avoid that (Zibi, should we make it easier to do so?). We'd also need the developer to pass in the animacy information ($object.animacy) about the object which would require code changes in the app! It seems that a much simpler and scalable approach would be for the developer to create two separate strings: flagUser and flagImage, and let localizers create dedicated translations for each which would also work well for the Sorbian languages. Some redundancy is good in localization. -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
