Add Textdomain Support

[kevinmartin]

Using either syntax:

<span translate="testDomain">Hello</span>
<span translate translate-domain="testDomain">Hello</span>

Works with Contexts/Interpolation and Plurals
Tests are included

[kevinmartin]

There are no breaking changes. When you don't specify a textdomain, it defaults to "default".

[rubenv]

Unless there's a really compelling case to add domains, I'd rather not have them.

Domains add little value: you can solve the same problems by reorganising your source code (make separate catalogues for multiple folders) and a translation memory.

[kevinmartin]

I will give you a few reasons for having domains:

• Developing an app with a plugin system (like Wordpress) where each plugin should be on its own domain
  • http://codex.wordpress.org/I18n_for_WordPress_Developers
• If you're working on a large project/app that can be split up into sections (Look at the screenshot below)
• If you want to separate "public" strings from "admin" strings
• Splitting a subset of an application for export (as @adepretis mentioned)

Screenshot for one of my Transifex projects

I posted this screenshot in #95. Your response was that I could have a directory like so:

src/accounts/
src/businesses/
src/capital/
...

Which my project does. But the problem here is when I have strings that can be used across multiple controllers/sections of the project, like the Tour, Locations, and Default. In this case, those strings will be split up around each of the other domains.

Gettext Textdomains were added for a reason. Why not add them since they are used by other people, like myself and @adepretis. The difference is only a couple dozen bytes and tests are included.

[thewilli]

Unless there's a really compelling case to add domains, I'd rather not have them.

Here's another one: Words exist where verb and substantive are equal in English, but may not in another language. Consider the word File that can be used as a column header for file names, and a button that is used to file an entry. When translating to German, two different translations are needed. Both strings may occur within the same page and cannot be separated easily.

I recently had such a case, and the only workaround for me was to use identifier (like LABEL_BUTTON_FILEENTRY), which unnecessarily increased the translation effort. If I had domains, I could easily separate those two strings.

[rubenv]

@thewilli Have a look at #53. What you describe is a use case of contexts, not domains (similar but different concept). Support for that is coming (we just need to finish the tools-side of things).

[kevinmartin]

@rubenv, agreed that what @thewilli suggested is a use case for contexts and not domains. But each of the other reasons are very much compelling reasons to support domains.

If you need me to work on the tool-side of things to support the extraction of strings with textdomain support, I can. I just don't want to waste my time if you're not going to be adamant about not supporting this feature.

Please consider this feature. They are part of the spec for a reason.

[mtr]

I really appreciate your efforts to get angular-gettext to support domains, @kevinmartin. I totally agree that gettext domains were added for a reason, and I don't understand why someone would deliberately cripple a gettext library implementation by not supporting them. I like your suggested filter syntax too.

My use cases actually match two of your examples above:

• "If you're working on a large project/app that can be split up into sections"
• "If you want to separate 'public' strings from 'admin' strings"

+1 for this feature, and great work, @kevinmartin!

[mtr]

We really need this feature in a couple of projects I'm working on. I've experienced problems trying to convince @rubenv based on GNU gettext's 20-year long history and our experiences using it during that time (well, since 1996 for my own sake): rubenv/grunt-angular-gettext#13. In this case, I think you've done a much better job trying to convince him, and anyone else, about the necessity of this feature. You've even provided pull-request with passing tests.

Therefore I am wondering if you, @kevinmartin, would be willing to maintain your fork in parallel with angular-gettext for some time? If so, we are more than happy to use your repo instead of this one. I know that one should really try to avoid forking an open source project, but sometimes it might be needed.

Update:
I'm sorry if I came off as rude. I didn't intend to. I've just grown a bit frustrated. I realize that it's asking to too much of anyone to start maintaining a fork, so I've "removed" that part (keeping it for reference). I think I'll just use this pull request for now, and if that means we'll have to maintain it ourselves, then so be it. Thank you both, @rubenv and @kevinmartin, for your great work. I really appreciate it.

[kevinmartin]

@mtr, I would be willing to create a fork, but I cannot guarantee that it will stay up to date with @rubenv's changes. I am implementing translations on my app tomorrow and I need this feature done by then.

Unfortunately, there is no textdomains extractor at the moment, either. I am willing to create it, but once again, I'd rather it be supported by the main project than a fork.

@rubenv, please recognize the need for this feature from many different commenters. I am willing to create the extractor and whatever else is needed to have this small feature come to fruition.

[gabegorelick]

But the problem here is when I have strings that can be used across multiple controllers/sections of the project, like the Tour, Locations, and Default. In this case, those strings will be split up around each of the other domains.

@kevinmartin, can you provide more information on this example? I'm having a hard time picturing this.

[kevinmartin]

@gabegorelick, @rubenv suggested that I split up my .pot files based on the controller/section. The problem in the example above is that the project aforementioned has a tour on many of it's pages.

We extracted all of the tour strings into it's own .pot file called tour.pot. This is great, because our marketing experts were able to take better control over those strings than our other translators. We can't do this without domains.

The other issue is with Locations. In locations, we have every country and US states translatable. We use these translations across many of our controllers. Because of this, we would not have a centralized location for our locations translations and they will be duplicated across every controller. This is both counter-productive and not DRY (Don't Repeat Yourself).

At the end of the day, as well, more strings also means more I have to pay in Transifex.

[gabegorelick]

I think I finally get it. Thanks for humoring me :)

I can get behind this in principle. If your catalogs truly are cross
cutting, then domains are useful. And after all, the dgettext family
of functions exist for a reason, and who are we to question the wisdom of
the gettext API? Sure, the majority of the time your catalogs should mirror
the structure of your project, but for when that's truly impossible or
impractical, domains are invaluable.

Disclaimer: my opinion doesn't mean anything

On Friday, November 14, 2014, Kevin Jose Martin [email protected]
wrote:

@gabegorelick https://github.com/gabegorelick, @rubenv
https://github.com/rubenv suggested that I split up my .pot files based
on the controller/section. The problem in the example above is that the
project aforementioned has a tour on many of it's pages.

We extracted all of the tour strings into it's own .pot file called
tour.pot. This is great, because our marketing experts were able to take
better control over those strings than our other translators. We can't do
this without domains.

The other issue is with Locations. In locations, we have every country and
US states translatable. We use these translations across many of our
controllers. Because of this, we would not have a centralized location for
our locations translations and they will be duplicated across every
controller. This is both counter-productive and not DRY (Don't Repeat
Yourself).

At the end of the day, as well, more strings also means more I have to pay
in Transifex.

—
Reply to this email directly or view it on GitHub
#115 (comment)
.

[gabegorelick]

I want to land support for contexts before we consider this, especially since some of the APIs conflict with how contexts would get implemented, e.g. getStringForm.

@kevinmartin and anyone else who wants to help, please take a look at rubenv/angular-gettext-tools#55 and give feedback. You all seem like smart people, so I value your opinions.

[rubenv]

First of all, apologies for the radio silence. I was out in Africa and swamped by work upon returning.

Recapping from #95:

I'm not opposed to adding features that fix problems, but I've always felt that domains is one of those features that doesn't really solve anything new in the context of a web app.

We shouldn't blindly follow what gettext does, just because gettext does it. Gettext is 20 years old and things have changed quite a lot in the last two decades. Angular-gettext deviates in other areas as well: look at how interpolation is handled in gettext: that would be totally unsuitable for an Angular.JS app, instead we use the Angular.JS interpolation, which fits us much better.

But if there's a real problem that cannot be fixed, I'm all for adding it. Case in point: contexts.

Now as for structuring your project differently based on a dependency: I'm not convinced you should. Grunt has such an amazing wealth of file matching power built-in that you can structure your catalogs pretty much any way you want.

So back to your example @kevinmartin:

@gabegorelick, @rubenv suggested that I split up my .pot files based on the controller/section. The problem in the example above is that the project aforementioned has a tour on many of it's pages.

We extracted all of the tour strings into it's own .pot file called tour.pot. This is great, because our marketing experts were able to take better control over those strings than our other translators. We can't do this without domains.

I'm assuming each page looks something like this:

+----------------------+
|  Tour           [x]  |
+----------------------+
Content

Given that the tour will work the same on each page, it's probably a directive of some sort. Why not have it reference a file and use ngInclude and give the file a _tour.html suffix.

Which leads to:

about.html
about_tour.html
...

Or put them in a separate folder:

about.html
tour/about.html

Why yes, I'm contradicting myself here: this is a different structure. But I'd argue that it's a better one: it puts all the tour content in an easy to recognize location, which makes it even easier for the marketing specialists to take ownership.

You can configure grunt with file patterns that put each string in non-tour pages in one catalog and each tour page in another catalog.

Is it a hack? Yup, but only slightly. Annotating each and every string with a domain is an even greater hack, at the cost of much added complexity.

Have you tried an approach like this? Or at least considered it?

It's not that I don't want domains, it's that it adds loads of pain which I wouldn't recommend to anyone, while you can obtain pretty much the same result in other ways (though we obviously disagree on that).

The other issue is with Locations. In locations, we have every country and US states translatable. We use these translations across many of our controllers. Because of this, we would not have a centralized location for our locations translations and they will be duplicated across every controller. This is both counter-productive and not DRY (Don't Repeat Yourself).

We pretty much have the same situation (with countries). I'm quite sure how this is a problem. Why don't you throw all these strings into one place (as in a factory or a service) and reference them from each controller? Could you elaborate a bit further on this one, perhaps I'm misunderstanding the issue?

[burzum]

👍 I would really appreciate if this would be merged into this project. Well done @kevinmartin!

[ThomasHambach]

What is the status on this implementation? I am for one definitely looking for such functionality.

[netstyler]

Would be a great feature! Why is it still not merged? ;)

[tagoh]

I'm surprised this feature isn't yet implemented. it is required to support the internationalization on projects which uses multiple modules like AngularJS as this project is also supposed to work on, right?

[rubenv]

The full reasoning why this won't go in is here: #115 (comment)

I'm closing this issue. Anyone who can demonstrate a common real-life problem that is currently impossible with angular-gettext: feel free to open a new issue. Fact is that a good project setup removes the need for domains: proper project structure has large benefits outside i18n alone.