Update gnc-commodity.cpp for finance-quote 1.63 #2033

pkryger · 2024-10-17T10:02:54Z

A few weeks ago @bpschuck asked for help with updating Gnucash for recent version of finance-quote. I hope this work a reasonable starting point.

I run the following code in [finance-quote-wrapper](https://github.com/Gnucash/gnucash/blob/05aadd0/libgnucash/quotes/finance-quote-wrapper.in#L114) to get multiple quote sources (i.e. more than one module):

use Finance::Quote;
my %qf = $q->get_features();
my $qm = $qf{quote_methods};
while (my ($k, $v) = each %$qm) {
    if (@$v > 1) {
        print "$k => @$v\n";
    }
}

Which yielded the following methods:

nasdaq => AlphaVantage FinanceAPI Fool GoogleWeb IEXCloud MarketWatch StockData YahooJSON
india => BSEIndia NSEIndia
europe => ASEGR Bourso BVB Consorsbank Sinvestor Stooq Tradegate XETRA
ukfunds => FTfunds MorningstarUK
canada => AlphaVantage TMX
usa => AlphaVantage FinanceAPI Fool IEXCloud YahooJSON
nyse => AlphaVantage FinanceAPI Fool GoogleWeb IEXCloud MarketWatch StockData YahooJSON

Then got single quote sources list using the script above, but used @$v == 1. Cross checked with finance-quote/Modules-README.yml, and tried to apply the following rules, while updating the list of modules in gnc-commodity.cpp:

if method names a country and has a working module - move it to multi source modules,
if module has been marked as failing - removed from the list,
if module has been marked as working and has been present in the list - left it as is (no further check),
if module has been marked as working, was not present in the list, and doesn't need an API key - added it to the list if and only if I could fetch a quote,
if module has been marked as working and requires an API key, then added it to the list.

While I think this work is probably a reasonable first cut, I think the following comments and questions should be at least reviewed by someone with more experience in this subject:

Used FinanceAPI instead of yahoo_json in multiple quote sources descriptions.
India Mutual - intiamutual looks like a multiple quote source, but has only one source, leave as is?
Highlighting other single source countries already in list: australia, dutch indiamutual, france, and romania.
Added more single source countries to multiple quote sources: india, hungary, greece, and poland.
Should aufund be added to multiple quote sources?
troweprice has been in multiple quote sources, but it has only one module. Not sure why. Removed from multiple quote sources. Also removed troweprice_direct in favour of troweprice in the single quote sources. Added as alternative in manual.
Added both tratedate and xetra as they seem to use more specific URL than sinvestor does.
Should tsx be renamed to tmx for Toronto Stock eXchange? The list originally had tsx (left it as is). Alternatively change the name to Toronto Stock eXchange (TMX), CA to highlight what TMX is.
bats - omitted in favour of googleweb. Or shall I add it, as say BATS Global Markets, US with a link in manual pointing to https://cboe.com (per Wikipedia)
tradeville - omitted in favour of bvb.
mstaruk - omitted, in favour of morningstaruk that has already been in the list. Added as alternative in manual.
Omitted all sources from hu module, that is failing ATM, that is: bamosz, bet, hufund, hustock, and hu. Moved section to deprecated in manual.
morningstarau - omitted, module is failing ATM.
oslobors - omitted, module is failing ATM.
cse - added, module is actually working (marked as failing in Modules-README.yml, will send a separate PR to address this).
comdirect - strictly speaking it is failing in 1.63, but fixed recently - included.

There's a complimentary Gnucash/gnucash-docs#345 to update relevant tables in gnucash-docs manual.

Since the change itself doesn't affect any logic (merely updates list contents) I believe a verification I performed with ninja check in debian:stable container should be sufficient.

jralls · 2024-10-18T00:44:51Z

Thanks. This at least brings the pick lists more or less up to date.

Removing sources from the list is less helpful than one might think unless F::Q has stopped providing them altogether because everything F::Q returns in a sources query gets listed: If it isn't in the single or multi lists it shows up in the unknown list.

To your details, most are fine. One exception:

Used FinanceAPI instead of yahoo_json in multiple quote sources descriptions.

How about fool instead? It doesn't need an API like financeapi.

You had some questions:

India Mutual - intiamutual looks like a multiple quote source, but has only one source, leave as is?

It's in both as are dutch and romania. As you note in the next two bullets it's not the only multiple that's really an alias for a single source. Remove all three of them from single_quote_sources.

Highlighting other single source countries already in list: australia, dutch indiamutual, france, and romania.

Added more single source countries to multiple quote sources: india, hungary, greece, and poland.

Which makes multisource a bit misleading. It's also redundant to have more that one source pointing at a single function; on the other hand it could be a useful abstraction should any of the primary source names be changed: Users wouldn't have to change their selections. But we should remove the ellipses where the list of sources is complete.

Should aufund be added to multiple quote sources?

I suppose, to be symmetrical with indiamutual.

Should tsx be renamed to tmx for Toronto Stock eXchange?

That just changes the UI unnecessarily. Leave it as-is.

pkryger · 2024-10-18T15:01:32Z

Thanks. This at least brings the pick lists more or less up to date.

Glad I can help ☺️.

[...]

Used FinanceAPI instead of yahoo_json in multiple quote sources descriptions.

How about fool instead? It doesn't need an API like financeapi.

I decided to use full names of modules in order they are queried, limiting to two modules if there are 2 or more (but expanded the list in documentation).

It's also redundant to have more that one source pointing at a single function;

This is a comment for multiple quote sources, but I guess it applies to single quote sources as well. I put the following sources in previous comment, but let me reiterate:

tmx is exactly the same as tsx,
bats is exactly the same as googleweb,
tradeville is exactly the same as bvb,
mstaruk is exactly the same as morningstaruk,
troweprice_direct is exactly the same as troweprice.
I omitted the above in single_quote_sources list, even though Finance::Quote reports them in ->sources() call (they will show up as unknown). However:
xetra and tradegate use the same api as sinvestor, although with more specific queries (I left them in the list).

Removing sources from the list is less helpful than one might think unless F::Q has stopped providing them altogether because everything F::Q returns in a sources query gets listed: If it isn't in the single or multi lists it shows up in the unknown list.

Thank you for that clarification. This is what I got when using Gnucash. I also gather that sources that have been selected by user are stored as text (module name only) in a .gnucash file. When Gnucash opens such a file, source is still handled (i.e., price editor will show it as selected and one can fetch quotes for it as long as Finance::Quote recognises the source name). Is that correct? N.B., I personally relay on the latter as I have a hacked Finance::Quote installation with private modules on one computer that only fetches quotes, and doing most of accounting on another one where private modules are not available).

That means there are 2 sources of potentially unknown modules: the Finance::Quote and a .gnucash file. I also presume that Finance::Quote will keep adding and removing sources as state of the World changes: new quote sources appear, other disappear, some are renamed, other are merged, etc. To limit confusion as much as possible it would be nice if each source had a unique id that is communicated to Gnucash, but this is very difficult for humans to handle (at least with current interface). In any case Finance::Quote should not reuse names of sources. I.e. cse stands for Colombo Stock Exchange today. Should it disappear, and subsequently, say, a Cyprus Stock Exchange is added it should not use cse. But it is OK for name to disappear and then appear again as long as it has the same semantic (and preferably security codes). I.e. when there was no source for given country for a while. Are these assumptions correct?

jralls · 2024-10-18T17:13:13Z

Used FinanceAPI instead of yahoo_json in multiple quote sources descriptions.

How about fool instead? It doesn't need an API like financeapi.

I decided to use full names of modules in order they are queried, limiting to two modules if there are 2 or more (but expanded the list in documentation).

I think you missed the point: I'm suggesting replacing Yahoo JSON with Motley Fool instead of FinanceAPI because FinanceAPI requires an API key while Motley Fool and Yahoo don't. Considering the strict quotes/day limits on AlphaVantage maybe replace that with FinanceAPI.

I also gather that sources that have been selected by user are stored as text (module name only) in a .gnucash file. When Gnucash opens such a file, source is still handled (i.e., price editor will show it as selected and one can fetch quotes for it as long as Finance::Quote recognises the source name). Is that correct?

Yes, with a clarification: Sources are stored by the source name returned from F::Q's sources method, e.g. alphavantage. The module name, AlphaVantage.pm, isn't visible to GnuCash.

In any case Finance::Quote should not reuse names of sources. I.e. cse stands for Colombo Stock Exchange today. Should it disappear, and subsequently, say, a Cyprus Stock Exchange is added it should not use cse. But it is OK for name to disappear and then appear again as long as it has the same semantic (and preferably security codes). I.e. when there was no source for given country for a while. Are these assumptions correct?

I don't think F::Q has a way to enforce that. @bpschuck ?
Regardless, I trust that you have your private sources named in such a way that collisions with future F::Q names are unlikely.

bpschuck · 2024-10-18T17:32:45Z

On 10/18/24 10:13 AM, John Ralls wrote: I think you missed the point: I'm suggesting replacing Yahoo JSON with Motley Fool instead of FinanceAPI because FinanceAPI requires an API key while Motley Fool and Yahoo don't. Considering the strict quotes/day limits on AlphaVantage maybe replace /that/ with FinanceAPI.

On the other hand, I would bet that 1 or 2 years down the road it is far more likely the FinanceAPI module will work as is and YahooJSON may break a few times. Methods requiring API keys: Pros - far less likely to change over time Cons - limits on number of queries and/or throttling. Personally, since I'm only getting quotes each day for about 2 dozen securities and funds, I have switched all my YahooJSON sources to FinanceAPI.

In any case Finance::Quote should not reuse names of sources. I.e. cse stands for Colombo Stock Exchange today. Should it disappear, and subsequently, say, a Cyprus Stock Exchange is added it should not use cse. But it is OK for name to disappear and then appear again as long as it has the same semantic (and preferably security codes). I.e. when there was no source for given country for a while. Are these assumptions correct? I don't think F::Q has a way to enforce that. @bpschuck <https:// github.com/bpschuck> ?

Negative sir. Although future contributors could look in the Modules-README.yml file and see a module name has already been used. Not yet in that file, methods for each module. I *have* been thinking of that.

Regardless, I trust that you have your private sources named in such a way that collisions with future F::Q names are unlikely.

Nope. If CSE were to be removed and a year or two down the road someone creates a new unrelated module as in your example, nothing to stop that. Me, I'd name the module and method(s) something more identifiable as "Cyprus" and not "CSE". I guess I (or whoever may be the gatekeeper of F::Q in the future), could ask contributors to rename when reviewing pull requests. And the Hackers Guide/Docs could also contain a note asking contributors to look at the Modules-README.yml file and not reuse obsolete/removed module and method names. Bruce S.

jralls · 2024-10-18T22:02:13Z

And the Hackers Guide/Docs could also contain a note asking contributors to look at the Modules-README.yml file and not reuse obsolete/removed module and method names.

@bpschuck does Modules-README.yaml have sources removed before you created it in 2019?

bpschuck · 2024-10-18T23:23:58Z

On 10/18/24 15:02, John Ralls wrote: And the Hackers Guide/Docs could also contain a note asking contributors to look at the Modules-README.yml file and not reuse obsolete/removed module and method names. @bpschuck <https://github.com/bpschuck> does Modules-README.yaml have sources removed before you created it in 2019?

Negative sir. As far as I recall it started as a snapshot of what was in the package at the time. Back then Erik was still running the show and I was but a simple volunteer contributor. I primarily came up with the format and basic fields while I believe it was Vincent who did the initial grunt work of listing the modules and their related data. BTW @pkryger, including "poland" as multi-source when it's only referenced in Stooq.pm may not be a good idea. In the future if another module that is primarily for the Warsaw exchange is added and also advertises the "poland" method, then it makes sense. Because right now if someone were to use "poland" as a source, the *only* method used/tried would be the "stooq" method from Stooq.pm. Just my $0.02. Bruce S.

fellen · 2024-10-19T20:12:59Z

I run the following code in [finance-quote-wrapper](https://github.com/Gnucash/gnucash/blob/05aadd0/libgnucash/quotes/finance-quote-wrapper.in#L114) to get multiple quote sources (i.e. more than one module): […]

Before it gets lost you should add the final form of your procedure as separate page Update FQ Sources[Edit] to the wiki[/Edit] and link it in Project_Administration below Dependency Updates and [Edit]~~at the end~~ in the abstract (before the first section header)[/Edit] of Online_Quotes

fellen

At least for new sources we should add the region.
Think about a not US based user, who is looking for a source for their mixture of commodities. As the source names have been very cryptic at the beginning, the region is one criterion, which they should test,

fellen · 2024-10-19T21:03:08Z

libgnucash/engine/gnc-commodity.cpp

    { false, SOURCE_SINGLE, "Google Web, US Stocks", "googleweb" },
-    { false, SOURCE_SINGLE, "India Mutual", "indiamutual" },
+    { false, SOURCE_SINGLE, "IEX (Investors Exchange), US", "iexcloud" },
+    { false, SOURCE_SINGLE, "Market Watch", "marketwatch" },


Region? Seems to be US based.

Yeah - but I was able to find quotes for Japanees, Chineese, Australian, German, UK, and Polish based stocks there. They seem to be positioning themselves similarly to say Bloomberg. Leaving this and other sources that are not clear to me yet as open issues for now.

Let's continue the discussion here

fellen · 2024-10-19T21:03:53Z

libgnucash/engine/gnc-commodity.cpp

    { false, SOURCE_SINGLE, "Morningstar, GB", "morningstaruk" },
    { false, SOURCE_SINGLE, "Morningstar, JP", "morningstarjp" },
+    { false, SOURCE_SINGLE, "Motley Fool", "fool" },


libgnucash/engine/gnc-commodity.cpp

fellen · 2024-10-19T21:05:46Z

libgnucash/engine/gnc-commodity.cpp

    { false, SOURCE_SINGLE, "SIX Swiss Exchange shares, CH", "six" },
    { false, SOURCE_SINGLE, "Skandinaviska Enskilda Banken, SE", "seb_funds" },
-    { false, SOURCE_SINGLE, "Sharenet, ZA", "za" },
+    { false, SOURCE_SINGLE, "StockData", "stockdata" },


fellen · 2024-10-19T21:06:14Z

libgnucash/engine/gnc-commodity.cpp

-    { false, SOURCE_SINGLE, "T. Rowe Price, US", "troweprice_direct" },
+    { false, SOURCE_SINGLE, "Tradegate, DE", "tradegate" },
+    { false, SOURCE_SINGLE, "Treasury Direct bonds, US", "treasurydirect" },
+    { false, SOURCE_SINGLE, "Twelve Data", "twelvedata" },


libgnucash/engine/gnc-commodity.cpp

bpschuck · 2024-10-19T23:53:43Z

FYI ASX (native method "asx", also advertises "australia") is failing and will be removed in F::Q v1.64. MorningStarAU (native "morningstarau", advertises "aufunds") is also failing. Being researched for possible fix by F::Q v1.65 (not v1.64). Bruce S.

jralls · 2024-10-20T00:32:53Z

ASX (native method "asx", also advertises "australia") is failing and will be removed in F::Q v1.64.

There are a bunch of Australian GnuCash users of that price source. Please flag that it's got problems on gnucash-user and see if anyone steps up to maintain it.

bpschuck · 2024-10-20T01:05:22Z

On 10/19/24 5:33 PM, John Ralls wrote: ASX (native method "asx", also advertises "australia") is failing and will be removed in F::Q v1.64. There are a bunch of Australian GnuCash users of that price source. Please flag that it's got problems on gnucash-user and see if anyone steps up to maintain it.

There has been an issue opened since May.

pkryger

ASX (native method "asx", also advertises "australia") is failing and will be removed in F::Q v1.64.

Add @bpschuck: should I remove it with this effort? Or give it some time?

libgnucash/engine/gnc-commodity.cpp

pkryger · 2024-10-20T11:52:59Z

libgnucash/engine/gnc-commodity.cpp

    { false, SOURCE_SINGLE, "Google Web, US Stocks", "googleweb" },
-    { false, SOURCE_SINGLE, "India Mutual", "indiamutual" },
+    { false, SOURCE_SINGLE, "IEX (Investors Exchange), US", "iexcloud" },
+    { false, SOURCE_SINGLE, "Market Watch", "marketwatch" },


Yeah - but I was able to find quotes for Japanees, Chineese, Australian, German, UK, and Polish based stocks there. They seem to be positioning themselves similarly to say Bloomberg. Leaving this and other sources that are not clear to me yet as open issues for now.

Let's continue the discussion here

jralls · 2024-10-20T15:14:25Z

Separate issue, shouldn't the names be marked for translation?

This seems like a non trivial issue to me

On the surface it's pretty trivial, you just wrap the strings with _(…) and they appear on Weblate and get translated. The fact that several of them are translated from their real names into English is interesting, but not really a problem. It's entirely possible that the translators for their original languages will offer better English translations given the opportunity.

bpschuck · 2024-10-20T18:08:40Z

On 10/19/24 5:33 PM, John Ralls wrote: ASX (native method "asx", also advertises "australia") is failing and will be removed in F::Q v1.64. There are a bunch of Australian GnuCash users of that price source. Please flag that it's got problems on gnucash-user and see if anyone steps up to maintain it.

There has been an issue opened since May.

The ASX source "sort of" works. It uses 2 different URLs, if the first one fails it tries its second URL. The 1st URL always fails. ASX is utilizing a JavaScript tool called Incapsula. The 2nd URL, while providing basic price data, does not include a trade date. I assumed that since there have been no issues raised on the trade date not being included that there are few users of the module.

bpschuck · 2024-10-20T22:15:24Z

ASX (native method "asx", also advertises "australia") is failing and will be removed in F::Q v1.64.

Add @bpschuck: should I remove it with this effort? Or give it some time?

@pkryger,

Leave it for now.

However, while doing some cleanup I found IEXCloud has been retired. Definitely will be removed in F::Q v1.64.

"We have retired IEX Cloud. All IEX Cloud products and support concluded on August 31, 2024. To help customers with this transition, we have signed a referral agreement with Intrinio, a full service data management company."

A quick look at Intrinio I did not find free or inexpensive data plans.

fellen · 2024-10-21T07:31:33Z

Separate issue, shouldn't the names be marked for translation?

This seems like a non trivial issue to me

On the surface it's pretty trivial, you just wrap the strings with _(…)

My pragmatical view:
We have already 5k+ translatable messages and I see @SziaTomi over a year almost daily work to complete hu.po.
Terms like borsa_italiana would I consider as name, which are usually not translated.
Additionally messages like 'bvb' would require a msgcontext or a translator comment explaining the meaning. We get more overhead than usage.
I18N

pkryger · 2024-10-21T11:51:24Z

Then SG+, PL+, … would be helpful.

I guess this is source based. While PL+ makes sense for stooq (it covers many Polish funds, that are probably not found in other places, I wouldn't go as far as saying that twelvedata is a Singapore first source. It seems to me they wan't to be a truly mutlinational one, like bloomberg or marketwatch. Granted: the latter two are based in US and US is the biggest financial market in the world, and I think they also have a good coverage of other asset classes (i.e., funds, as well as municipal and company issued bonds). Probably the best in US, but I can see UK pension funds on Bloomberg as well. I'd probably go as far as removing the US from alphavantage.

When I searched symbols of german funds, [...]

Should the regions end up in documentation, perhaps it would warrant adding an extra region column. That way the description can be more verbose, i.e., for stooq it can be something like: PL (primarily), mutlinational. We can even add asset classes (stock, fund, bonds, commodities, crypto, etc.). Perhaps as a separate column as well. But: I don't feel particularly competent or knowledgeable to fill such extra columns.

What's more: what data is provided by each source could change. I could easily see players to add and remove regions and asset classes as they sing and end contracts with other data providers. This is out of control of Finance::Quote, as it merely provides a common interface to these sources. So keeping these columns up to date seems like a never ending task.

Perhaps Wiki is a good place for that, as updating sources should be easier. Maybe even provide a link to the table in Security Editor?

All in all please let me know if I should remove regions from code.

jralls · 2024-10-21T14:40:34Z

Should the regions end up in documentation, perhaps it would warrant adding an extra region column. That way the description can be more verbose, i.e., for stooq it can be something like: PL (primarily), mutlinational. We can even add asset classes (stock, fund, bonds, commodities, crypto, etc.). Perhaps as a separate column as well.

In documentation it can be written out in complete sentences like "Stooq: Comprehensive for Polish securities, also provides prices for German, French, UK and US stocks."

But: I don't feel particularly competent or knowledgeable to fill such extra columns.

Another reason for it to be in the wiki instead of the manual, so lots of users can contribute what they've learned about particular sources.

jralls · 2024-10-21T15:01:00Z

We have already 5k+ translatable messages and I see @SziaTomi over a year almost daily work to complete hu.po.

It is difficult to respond to that without sarcasm. You're suggesting that we should deliberately make it impossible to translate parts of the UI for what you suppose to be the convenience of translators. @SziaTomi is putting in that work because they want a complete translation of the UI into Hungarian. It seems very unlikely to me that they want you deciding that there are parts that they have to leave in English.

Terms like borsa_italiana would I consider as name, which are usually not translated.
Additionally messages like 'bvb' would require a msgcontext or a translator comment explaining the meaning. We get more overhead than usage.

borsa_italiana and bvb are the internal source-ids that the combo selects. That's code, code doesn't get translated, and you know that. "Borsa Italiana" (which should be rendered in English as "Italian Stock Exchange") and "Bursa de Valori Bucuresti" (similarly "Bucharest Stock Exchange") are the corresponding UI labels that should be English in code and marked for translation just like every other UI string.

pkryger · 2024-10-21T15:12:49Z

Terms like borsa_italiana would I consider as name, which are usually not translated.
Additionally messages like 'bvb' would require a msgcontext or a translator comment explaining the meaning. We get more overhead than usage.

borsa_italiana and bvb are the internal source-ids that the combo selects. That's code, code doesn't get translated, and you know that. "Borsa Italiana" (which should be rendered in English as "Italian Stock Exchange") and "Bursa de Valori Bucuresti" (similarly "Bucharest Stock Exchange") are the corresponding UI labels that should be English in code and marked for translation just like every other UI string.

My bad - I shouldn't have use quote source names when I ment entity names. But you have answered my question. I updated names in the list to use English names. Also marked strings for translations.

fellen · 2024-10-21T19:57:57Z

libgnucash/engine/gnc-commodity.cpp

-    { false, SOURCE_SINGLE, "Yahoo as JSON", "yahoo_json" },
-    { false, SOURCE_SINGLE, "Yahoo Web", "yahooweb" },
-    { false, SOURCE_SINGLE, "YH Finance (FinanceAPI)", "financeapi" },
+    { false, SOURCE_SINGLE, N_("Alphavantage"), "alphavantage" },


IMHO we should then add a msgcontext, e.g.:
{ false, SOURCE_SINGLE, C_("FQ source", "Alphavantage"), "alphavantage" },
…

Oops, we need a delay. I fear we have no macro for that defined, @jralls ?

It should call g_dpgettext2 (…) as used in gnucash/gnome/assistant-stock-transaction.cpp.

Oops, we need a delay. I fear we have no macro for that defined, @jralls ?

No worries. The macro comes from glib/gi18n.h and it's already flagged for xgettext.

{ false, SOURCE_SINGLE, C_("FQ source", "Alphavantage"), "alphavantage" },

A poor choice, that's a trademark. Nobody's going to think it's anything else. Likely nobody will translate it, either, considering it's a company name. "Any of the countries are much better exemplars of needing a translation context. But that raises an interesting question: Some of the non-English user names, like Borsa Italiana and Bursa de Valori Bucuresti, are descriptive and should be rendered in English in gnc-commodity.cpp and translated back, but others (FinanzPartners perhaps?) are company names trademarked in their countries; those should be left alone. I suppose that they shouldn't be marked for translation either. Or am I overthinking this?

I know that the following is probably mudding waters even more, instead of driving to a solution, but I think it's even more subtle.

When I originally added Borsa Italiana I went to their home pages and it doesn't seem they are encouraging translation of their name. So: is it a trademark that should be left as is?

Some languages that don't use latin script may want to translate names that could be recognised as trademarks. One example could be Commerzbank that could be rendered in Cyrillic script as Коммерцбанк. I know that French, despite using latin script, also like to stick to their own language. But not sure how prolific it is in accounting applications translations.

There's even more. @bpschuck mentioned, that future versions of GnuCash would use dynamically just out of curiosity, how such strings that come from another application, could be translated?

When I originally added Borsa Italiana I went to their home pages and it doesn't seem they are encouraging translation of their name. So: is it a trademark that should be left as is?

The intro on that webpage says "Borsa Italiana has been founded after the privatisation of the exchange" and "from 29th April 2021, Borsa Italiana is part of Euronext Group." So I guess that it is indeed a company name.

You have a good point about translating (or transliterating, but for our purposes there's no difference) for non-Latin scripts. That argues for marking all of them and providing a translator comment on the ones that are company names. I guess that might turn out to be all of them.

You're right that translating strings from another project requires that project to have a message catalog to retrieve the translations from and Finance::Quote at present doesn't. Using methodinfo in GnuCash will require a pretty big design change and (as @bpschuck pointed out in his reply) another piece of that redesign needs to be a way to handle obsolete sources. Let's keep this PR focused on the current design.

jralls · 2024-10-22T00:02:47Z

@pkryger

My bad - I shouldn't have use quote source names when I meant entity names.

You didn't, @fellen did.

fellen · 2024-10-28T07:36:11Z

libgnucash/engine/gnc-commodity.cpp

-    { false, SOURCE_SINGLE, "Yahoo as JSON", "yahoo_json" },
-    { false, SOURCE_SINGLE, "Yahoo Web", "yahooweb" },
-    { false, SOURCE_SINGLE, "YH Finance (FinanceAPI)", "financeapi" },
+    { false, SOURCE_SINGLE, C_("FQ Source", "Alphavantage"), "alphavantage" },


No, you want NC_("FQ Source", "Alphavantage"), "alphavantage"
and then you have to search each usage and decide translate it —C_("FQ Source", "…")I think — (shown to the user) or not (stored in the file or log files)

I used NC for all as suggested. However, my time has become more limited now and not sure if I will have enough of it to do anything more involved. Because of that constraint if this is not what you've been looking for, I propose to remove the translation markers, merge just the updated list and proceed with translations as a separate PR.

It's not so hard: The user name is retrieved in exactly one place, so to perform the translation you need only do

--- a/gnucash/gnome-utils/dialog-commodity.cpp +++ b/gnucash/gnome-utils/dialog-commodity.cpp @@ -778,7 +778,7 @@ gnc_ui_source_menu_create(QuoteSourceType type) supported = gnc_quote_source_get_supported(source); gtk_list_store_append(store, &iter); gtk_list_store_set(store, &iter, - SOURCE_COL_NAME, name, + SOURCE_COL_NAME, C_("FQ Source", name), SOURCE_COL_FQ_SUPPORTED, supported, -1);

@jralls Thanks for explaining this. I think I begin to understand how the i18n works in GTK. I've taken inspiration from 11458bf and used g_dpgettext2 to avoid string concatenation.

jralls · 2024-10-31T17:57:13Z

Thanks!

Update gnc-commodity.cpp for finance-quote 1.63

5fc7687

pkryger mentioned this pull request Oct 17, 2024

Update Appendix A for finance-quote 1.63 Gnucash/gnucash-docs#345

Closed

pkryger added 2 commits October 18, 2024 15:25

Add back cse - Colobmo Stock Exchange to single_quote_sources

2e734b3

Remove ellipses from multiple_quote_sources where lists are complete

700f8ca

pkryger force-pushed the update-for-fq-1.63 branch from 2a4420c to 2349832 Compare October 18, 2024 14:27

Add morningstarau to single and aufunds to multiple _quotes_sources

84e6a21

pkryger force-pushed the update-for-fq-1.63 branch from 2349832 to 84e6a21 Compare October 18, 2024 14:56

fellen reviewed Oct 19, 2024

View reviewed changes

pkryger added 2 commits October 20, 2024 11:58

Add regions to S-Investor and OnVista quote sources

b7b7df5

Use UTF8 ellipsys character in mutliple qoute sources lists

1911bf5

pkryger commented Oct 20, 2024

View reviewed changes

pkryger added 2 commits October 21, 2024 12:53

Athens is Greece

a4b7c9b

Remove US from alphavantage

9e4cd9e

Use English names for Italian and Bucharest stock exchanges

3dd9a70

fellen reviewed Oct 21, 2024

View reviewed changes

pkryger force-pushed the update-for-fq-1.63 branch from 22a8b61 to c8c493a Compare October 22, 2024 08:00

pkryger mentioned this pull request Oct 23, 2024

Remove Finance::Quote appendix Gnucash/gnucash-docs#346

Merged

fellen requested changes Oct 28, 2024

View reviewed changes

pkryger force-pushed the update-for-fq-1.63 branch from c8c493a to 4356aa5 Compare October 28, 2024 07:58

Mark quote source strings for translations

cba8682

pkryger force-pushed the update-for-fq-1.63 branch from 4356aa5 to cba8682 Compare October 29, 2024 09:31

code-gnucash-org merged commit 274c033 into Gnucash:stable Oct 31, 2024
4 checks passed

Update gnc-commodity.cpp for finance-quote 1.63 #2033

Update gnc-commodity.cpp for finance-quote 1.63 #2033

Conversation

pkryger commented Oct 17, 2024 • edited Loading

jralls commented Oct 18, 2024

pkryger commented Oct 18, 2024

jralls commented Oct 18, 2024

bpschuck commented Oct 18, 2024 via email

jralls commented Oct 18, 2024

bpschuck commented Oct 18, 2024 via email

fellen commented Oct 19, 2024 • edited Loading

fellen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pkryger Oct 20, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bpschuck commented Oct 19, 2024 via email

jralls commented Oct 20, 2024

bpschuck commented Oct 20, 2024 via email

pkryger left a comment

Choose a reason for hiding this comment

pkryger Oct 20, 2024 • edited Loading

Choose a reason for hiding this comment

jralls commented Oct 20, 2024

bpschuck commented Oct 20, 2024

bpschuck commented Oct 20, 2024

fellen commented Oct 21, 2024

pkryger commented Oct 21, 2024 • edited Loading

jralls commented Oct 21, 2024

jralls commented Oct 21, 2024

pkryger commented Oct 21, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pkryger Oct 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jralls commented Oct 22, 2024

Choose a reason for hiding this comment

pkryger Oct 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jralls commented Oct 31, 2024

pkryger commented Oct 17, 2024 •

edited

Loading

fellen commented Oct 19, 2024 •

edited

Loading

pkryger Oct 20, 2024 •

edited

Loading

pkryger Oct 20, 2024 •

edited

Loading

pkryger commented Oct 21, 2024 •

edited

Loading

pkryger Oct 22, 2024 •

edited

Loading

pkryger Oct 28, 2024 •

edited

Loading