ವಿಕಿಪೀಡಿಯ tcywiki https://tcy.wikipedia.org/wiki/%E0%B2%AE%E0%B3%81%E0%B2%96%E0%B3%8D%E0%B2%AF_%E0%B2%AA%E0%B3%81%E0%B2%9F MediaWiki 1.47.0-wmf.10 first-letter ಮಾದ್ಯಮೊ ವಿಸೇಸೊ ಪಾತೆರ ಬಳಕೆದಾರೆ ಬಳಕೆದಾರೆ ಪಾತೆರ ವಿಕಿಪೀಡಿಯ ವಿಕಿಪೀಡಿಯ ಪಾತೆರ ಫೈಲ್ ಫೈಲ್ ಪಾತೆರ ಮಾದ್ಯಮೊವಿಕಿ ಮಾದ್ಯಮೊವಿಕಿ ಪಾತೆರ ಟೆಂಪ್ಲೇಟ್ ಟೆಂಪ್ಲೇಟ್ ಪಾತೆರ ಸಕಾಯೊ ಸಕಾಯೊ ಪಾತೆರ ವರ್ಗೊ ವರ್ಗೊ ಪಾತೆರ ತಡ್ಯ ತಡ್ಯ ಪಾತೆರ ಕರಡು ಕರಡು ಪಾತೆರ TimedText TimedText talk ಮೋಡ್ಯೂಲ್ ಮೋಡ್ಯೂಲ್ ಪಾತೆರ Event Event talk ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ 0 4182 362716 362680 2026-07-12T14:54:54Z ChiK 1136 /* */ 362716 wikitext text/x-wiki {{Infobox writer <!-- for more information see [[:Template:Infobox writer/doc]] --> | name = ಮೊಗೇರಿ ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ | image size = 250px | pseudonym = | birth_date = 18-02-1918 | birth_place = ಮೊಗೇರಿ, [[ಕುಂದಾಪುರ]] ತಾಲೂಕು, [[ಉಡುಪಿ ಜಿಲ್ಲೆ]], [[ಕರ್ನಾಟಕ]] | death_date = 04-11-1992 | death_place = [[ಬೆಂಗಳೂರು]], Karnataka | occupation = ಕವಿ, ಬರಹಗಾರೆರ್, [[ಕನ್ನಡ]] ಪ್ರಾಧ್ಯಾಪಕೆರ್ | nationality = [[ಭಾರತ]] | period = | genre = ಕಥೆ | subject = | movement = ನವ್ಯ | influences = [[ರಾಮ ಮನೋಹರ ಲೋಹಿಯಾ]], [[ಶಾಂತವೇರಿ ಗೋಪಾಲಗೌಡ]] | influenced = | signature = | website = }} '''ಮೊಗೇರಿ ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ''' (೧೮.೨.೧೯೧೮–೧೪.೧೧.೧೯೯೨) ಆಧುನಿಕ ಕನ್ನಡ ಕವಿ. ಕೆಲವು ವ್ಯಾಖ್ಯಾನಕಾರೆರ್ ಅರೆನ್ "ಪೊಸ ಶೈಲಿದ" ಕಬಿತೆದ ಪ್ರವರ್ತಕೆ ಪಂಡ್ದ್ ಲೆಪ್ಪುವೆರ್. <ref>http://www.hinduonnet.com/thehindu/mp/2002/09/26/stories/2002092600660200.htm The Hindu - 26 September 2002</ref> ==ಜೀವನ ಚರಿತ್ರೆ== ಆರ್ [[ಕರ್ನಾಟಕ]] ರಾಜ್ಯದ [[ಉಡುಪಿ]] ಜಿಲ್ಲೆದ ಕರಾವಳಿ ಗ್ರಾಮ ಮೊಗೇರಿಡ್ ಪುಟ್ಟಿಯೆರ್. ಪ್ರಾಥಮಿಕ ಶಿಕ್ಷಣ ಮೊಗೇರಿ ಬೊಕ್ಕ [[ಬೈಂದೂರು]]ಡ್ ಮುಗಿದ್ ಕುಂದಾಪುರೊಡು ಪ್ರೌಢಶಾಲೆಗ್ ಪೋಯೆರ್.<ref>{{Cite web|title=Gopalakrishna Adiga Biography - Biography of Gopalakrishna Adiga|url=https://www.poemhunter.com/gopalakrishna-adiga/biography/|access-date=2022-01-22|website=Poem Hunter|language=en-us}}</ref> ''ಸಾಕ್ಷಿ'' ಪತ್ರಿಕೆದ ಸಂಪಾದಕೆರಾದ್ ಆರ್ ಕನ್ನಡ ಸಾಹಿತ್ಯನ್ ಜನಸಾಮಾನ್ಯೆರೆಗ್ ಕನಯೆರೆ ಸಹಾಯ ಮಲ್ತೆರ್.<ref name="hin3">{{usurped|[https://web.archive.org/web/20070313181327/http://www.hinduonnet.com/thehindu/2004/10/04/stories/2004100411610300.htm Gopalakrishna Adiga remembered]}} The Hindu - 4 October 2004</ref> ಅಡಿಗಾನ ಮಗೆ ಮನು ರಾಜು, ಸಿಎನ್ಎನ್ ದ ಹಿರಿಯ ರಾಜಕೀಯ ವರದಿಗಾರೆರ್.<ref>{{Cite web | url=http://www.cnn.com/profiles/manu-raju | title=CNN Profiles - Manu Raju - Chief Congressional Correspondent | website=[[CNN]] }}</ref> ಬೊಕ್ಕೊಂಜಿ ಮಗೆ, ಶರತ್ ರಾಜು, ಅಮೇರಿಕೊಡು ಒರಿ ಚಿತ್ರ ನಿರ್ದೇಶಕೆರ್. ==ವಿದ್ಯಾಭ್ಯಾಸ ಬೊಕ್ಕ ವೃತ್ತಿ== === ವಿದ್ಯಾಬ್ಯಾಸೊ === *ಅಡಿಗೆರ್ ಪ್ರಾಥಮಿಕ ಮೊಗೇರಿಡ್ ಬುಕ್ಕೊ ಪ್ರೌಢ ಶಿಕ್ಷಣೊನು ಬೈಂದೂರುಡ್ ಮಲ್ತೆರ್. *ಉನ್ನತ ಶಿಕ್ಷಣೊಗು ಆರ್ ಮೈಸೂರುದ ಮಹಾರಾಜ ಕಾಲೇಜಗ್ ಸೇರ್‌ಯೆರ್. ಇಂಗ್ಲೀಸ್‌ನ್ ಮುಕ್ಯೊ ವಿಸಯೊ ಆದ್ ದೆತೊಂದು ಐತ ಬಗೆಟ್ ಜಾಸ್ತಿ ಅಧ್ಯಯನೊ ಮಲ್ತ್‌ದ ಮೈಸೂರು ವಿಶ್ವವಿದ್ಯಾಲಯೊಡ್ದ್ ಬಿ.ಎ. ಆನರ್ಸ್ ಪದವಿನ್ ಪಡೆಯೆರ್‍. *ನಾಗ್ಪುರೊ ವಿಶ್ವವಿದ್ಯಾನಿಲಯೊಡ್ ಇಂಗ್ಲಿಸ್ ಎಂ.ಎ. ಪದವಿ ಪಡೆಯೆರ್. ===ವೃತ್ತಿ=== *ಮೈಸೂರು ಶಾರದ ಕಾಲೇಜುಡ್ ಇಂಗ್ಲೀಸ್‍ಡ್ ಉಪನ್ಯಾಸಕರಾದ್ ಸೇವೆ ಮಲ್ತ್‌ದೆರ್.<ref name="hin2">[https://web.archive.org/web/20040823112054/http://www.hindu.com/mag/2004/04/25/stories/2004042500260300.htm The Mysore generation] ''The Hindu'' - 25 Apr 2004.</ref> *ಸಂತ ಫಿಲೋಮಿನ ಕಾಲೇಜಿಡ್‍ ಪತ್ತ್ ವರ್ಸೊ ಸೇವೆ ಮಲ್ತೆ‌ರ್. *1960ಡ್ ಸಾಗರೋದ ಲಾಲ್ ಬಹದ್ದೂರ್ ಶಾಸ್ತ್ರಿ ಕಾಲೇಜಿಡ್ ಪ್ರಾಂಶುಪಾಲೆರಾದ್ ಸೇವೆ ಮಲ್ತ್‌ದೆರ್. *ಉಡುಪಿದ ಪೂರ್ಣಪ್ರಜ್ಞಾ ಕಾಲೇಜಿಡ್‌ ಸೇವೆ ಮಲ್ತ್‌ದೆರ್. 1950 ಬೊಕ್ಕ 1960 ದಶಕೊಡು ಅಡಿಗ [[ಮೈಸೂರು]]ಡ್ ಶಿಕ್ಷಕೆರಾದಿತ್ತೆರ್. ೧೯೬೪ ಡ್ದ್ ೧೯೬೮ ಮುಟ್ಟ ಸಾಗರ ಡ್ ಲಾಲ್ ಬಹದ್ದೂರ್ ಕಾಲೇಜಿಡ್ ಪ್ರಿನ್ಸಿಪಾಲ್ ಆದಿತ್ತೆರ್, ೧೯೬೮ ಡ್ದ್ ೧೯೭೧ ಮುಟ್ಟ [[ಉಡುಪಿ]] ಡ್ ಪೂರ್ಣ ಪ್ರಜ್ಞ ಕಾಲೇಜಿಡ್ ಪ್ರಿನ್ಸಿಪಾಲ್ ಆದಿತ್ತೆರ್.<ref name="bio">{{cite web|url=http://geocities.com/indian_poets/kannada.html |title=Indian Poets Writing In Kannada |access-date=2010-10-08 |url-status=bot: unknown |archive-url=https://web.archive.org/web/20091026144559/http://geocities.com/indian_poets/kannada.html |archive-date=26 October 2009 }} - Indian Poets</ref> ಅರೆನ ಶೈಲಿನ್ 1947ಡ್ ಬ್ರಿಟಿಷ್ ಆಡಳಿತ ಡ್ದ್ ಭಾರತೀಯ ಸ್ವಾತಂತ್ರ್ಯ ಚಳುವಳಿಗ್ ಪ್ರತಿಕ್ರಿಯೆ ಆದ್ ವರ್ಣನೆ ಮಲ್ತೆರ್. ಆಧುನಿಕ ಪಾಶ್ಚಾತ್ಯ ಸಾಹಿತ್ಯ ಬೊಕ್ಕ ಭಾರತೀಯ ಸಂಪ್ರದಾಯೊಡ್ದ್ ಸ್ಫೂರ್ತಿ ಪಡೆಯಿನ ಆರ್ "ಕಾಲೊದ ಮೋಸ ಬೊಕ್ಕ ಆತಂಕೊನು" ಚಿತ್ರಣ ಮಲ್ಪೆರೆ ಸುರು ಮಲ್ತೆರ್.<ref name="bio" /> ==ಕೆಲಸ ಮಲ್ಪುಂಡು== *''ಭವತರಂಗ'' - ೧೯೪೬ *''ಅನಾಥೆ'' - ೧೯೫೪ (ಕಾದಂಬರಿ) *''ಭೂಮಿ ಗೀತೆ'' - ೧೯೫೯ *''ಮಣ್ಣಿನ ವಾಸನೆ'' (ಪ್ರಬಂಧದ ಗ್ರಂಥ) - ೧೯೬೬ *''ವರ್ಧಮಾನ'' - ೧೯೭೨ *''ಇದಣ್ಣ ಬಯಸಿರಲಿಲ್ಲ'' (ಕವನೊಲು) - ೧೯೭೫ *''ಸಾಮಗ್ರ ಕಾವ್ಯ'' (ಕವನ ಸಂಕಲನ) - ೧೯೭೬ *''[https://web.archive.org/web/20090612035606/http://www.sirinudi.org/ಸಾಕ್ಷಿ/ಸಾಕ್ಷಿ.html] ಸಾಕ್ಷಿ'' (ಪತ್ರಿಕೆ) - ೧೯೬೨ ==Quotes(ಹೇಳಿಕೆ)== *"ಇರುವುದೆಲ್ಲವ ಬಿಟ್ಟು ಇರದುದರೆಡೆಗೆ ತುಡಿವುದೆ ಜೀವನ?" Is life leaving everything we have and craving for things which we do not have? *"ಮೌನ ತಬ್ಬಿತು ನೆಲವ"<ref>{{usurped|1=[https://web.archive.org/web/20050216074048/http://www.caswath.com/about-quotes.htm QUOTES about Aswath]}} - C. Aswath</ref> === ಮರಣೊ === *೧೪ ನವಂಬರ್, ೧೯೯೨. == ಸಾಹಿತ್ಯ ಸೇವೆ == ಅಡಿಗೆರ್ ಕಬಿತೆ, ಕತೆ, ಕಾದಂಬರಿ, ಇಮರ್ಸೆ, ಪ್ರಬಂದೊಲೆನ್ ಬರೆತೆರ್. === ಕಬಿತೆಲೆನ ಕೋಪೆ === *ಭಾವತರಂಗ - ೧೯೪೬ *ಅನಂತೆ- ೧೯೫೪( ಕಾದಂಬರಿ ) *ಭೂಮಿ ಗೀತಾ - ೧೯೫೯ *ಮಣ್ಣಿನ ವಾಸನೆ( ಪ್ರಬಂಧಗಳ ಪುಸ್ತಕ ) - ೧೯೬೬ *ವರದಮಾನ-೧೯೭೨ *ಇದನ್ನು ಬಯಸಿರಲ್ಲಿಲಾ ( ಕವನಗಳು ) - ೧೯೭೨ *ಕೊರಗ ಕಾವ್ಯ ( ಕವಿತೆಗಳ ಸಂಗ್ರಹ ) - ೧೯೭೬ *ಸಾಕ್ಷಿ ( ಮ್ಯಾಗಜೀನ್ ) - ೧೯೬೨ *"ಇರುವುದೆಲ್ಲವ ಬಿಟ್ಟು ಇರದುದರೆಡೆಗೆ ತುಡಿವುದೆ ಜೀವನ " *ಮೌನ ತಬ್ಬಿತು ನೆಲವ " == ಅಡಿಗೆರೆಗ್ ಸಂದ್‍ನ ಪ್ರಶಸ್ತಿಲು == ೧೯೬೮ಡ್ ಅಡಿಗೆರೆಗ್ ೫೦ ಒರ್ಸೊ ದಿಂಜಿನ ಸಂದರ್ಬೊಡು ಉಡುಪಿಡ್ ಕು.ಶಿ.ಹರಿದಾಸ ಬಟ್ರ್ ಬುಕ್ಕೊ ವಿಜಯನಾಥ ಶೇಣೈಯೆರ್ ಇಂಚಿತಿ ಸಾಹಿತ್ಯಾಭಿಮಾನಿಲು ಒಂಜಿ ಅಪೂರ್ಪೊದ ಜಂಬರೊ ಲಕ್ಕವೆರ್. ಅಯಿಟ್ ಪೊಸ ಪೀಲಿಗೆದ ಮಹತ್ವೊದ ಕವಿ, ಸಾಹಿತಿ, ವಿಮರ್ಶಕೆರಾಯಿನ ಲಂಕೇಶ್, ಚಂದ್ರಶೇಖರ ಕಂಬಾರ, ಎಂ.ಜಿ. ಕೃಷ್ಣಮೂರ್ತಿ, ಶಾಂತಿನಾಥ ದೇಸಾಯಿ, ಜಿ. ಎಚ್. ನಾಯಕ, ಕಿ ರಂ. ನಾಗರಾಜ. ಗಿರಡ್ಡಿ ಗೋವಿಂದರಾಜ, ಬನ್ನಂಜೆ ಗೋವಿಂದಾಚರ್ಯ, ಡಿ. ಎಸ್. ರಾಯಕರ್ ಇಂಚಿನಕುಲು ಸೇರ್ದಿತ್ತೆರ. ವಿಮರ್ಶಕೆ '''ನಿಸ್ಸಿಂ ಇಝೆಕಿಲ್''' ಪನ್ಪಿನಾರ್ 'ಅಡಿಗೆರ್ ಕನ್ನಡೊಡು ಬರೆಪ್ಪುನ ಒರಿ ಮಲ್ಲ ಭಾರತೀಯ ಕವಿ' ಪಂಡ್‍ದ್ ಕೊಂಡಾಟೊ ಮಲ್ತೆರ್. #೧೯೭೪ಡ್ ರಾಜ್ಯೊ ಸಾಹಿತ್ಯ ಆಕಾಡೆಮಿ ಪ್ರಶಸ್ತಿ ಬತ್ತ್ಂಡ್. #೧೯೭೫ಡ್ ಅಡಿಗೆರೆಗ್ `ವರ್ಧಮಾನ'ಕವನೊ ಸಂಕಲನೊಗು ಕೇಂದ್ರ ಸಾಹಿತ್ಯ ಆಕಾಡೆಮಿ ಪ್ರಶಸ್ತಿ ಬತ್ತ್ಂಡ್. #೧೯೭೯ಡ್ [[ಕೇರಳ|ಕೇರಳೊ]]ದ ಪ್ರತಿಷ್ಠಿತೊ `ಕುಮಾರ್ ಸಮ್ಮಾನ್' ಪ್ರಶಸ್ತಿ ಲಬ್ಯೊ ಆಂಡ್. #೧೯೮೦ಡ್ `ಸಮಗ್ರ ಕಾವ್ಯೊ'ಗು ಮೂಡಬಿದ್ರೆದ `ವರ್ಧಮಾನ' ಪ್ರಶಸ್ತಿ ತಿಕ್ಂಡ್. #೧೯೮೨ಡ್ ಪ್ಯಾರಿಸ್, ಯುಗೋಸ್ಲಾವಿಯಡ್ ನಡತ್ತ್‌ನ ವಿಶ್ವಕವಿ ಸಮ್ಮೇಳನೊದ ಆಹ್ವಾನಿತೆರಾದ್ ಭಾಗವಹಿಸದೆರ್. #೧೯೮೬ಡ್ ಮಧ್ಯಪ್ರದೇಸೊದ ಸರಕಾರೊ ಆರಂಭಿಸಯಿನ ಸುರುತ `ಕಬೀರ್ ಸನ್ಮಾನ್' ಅಡಿಗೆರೆ ಪಾಲ್‍ಗ್ ಬತ್ತ್ಂಡ್. #೧೯೮೮ಡ್ ಥ್ಯಾಲಂಡ್‍ದ ಬ್ಯಾಂಕಾಕ್ ನಗರೊಡು ನಡತ್ತ್‌ನ ಜಾಗತಿಕ ಕವಿ ಸಮ್ಮೇಳನೊಡು 'ವರ್ಲ್ಡ್ ಅಕಾಡೆಮಿ ಆಫ್ ಆರ್ಟ್ ಎಂಡ್ ಕಲ್ಚರ್' ಸಂಸ್ಥೆ ಆರೆಗ್ 'ಡೊಕ್ಟರ್ ಆಫ್ ಲಿಟರೇಚರ್' ಪ್ರಶಸ್ತಿ ಕೊರ್‌ದ ಗೌರವಿಸಾಂಡ್. #'ರಾಜ್ಯೋತ್ಸವ ಪ್ರಶಸ್ತಿ' #'ಪಂಪ ಪ್ರಶಸ್ತಿ'. == ಉಲ್ಲೇಕೊಲು == {{Reflist}} [[ವರ್ಗೊ:ಕವಿ|ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ]] [[ವರ್ಗೊ:ವ್ಯಕ್ತಿಲು]] [[ವರ್ಗೊ:ಕನ್ನಡ ಕವಿ]] tjr2u7i2ufsk50sifaabef8lwvusne8 362735 362716 2026-07-13T00:51:45Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362735 wikitext text/x-wiki {{Infobox writer <!-- for more information see [[:Template:Infobox writer/doc]] --> | name = ಮೊಗೇರಿ ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ | image size = 250px | pseudonym = | birth_date = 18-02-1918 | birth_place = ಮೊಗೇರಿ, [[ಕುಂದಾಪುರ]] ತಾಲೂಕು, [[ಉಡುಪಿ ಜಿಲ್ಲೆ]], [[ಕರ್ನಾಟಕ]] | death_date = 04-11-1992 | death_place = [[ಬೆಂಗಳೂರು]], Karnataka | occupation = ಕವಿ, ಬರಹಗಾರೆರ್, [[ಕನ್ನಡ]] ಪ್ರಾಧ್ಯಾಪಕೆರ್ | nationality = [[ಭಾರತ]] | period = | genre = ಕಥೆ | subject = | movement = ನವ್ಯ | influences = [[ರಾಮ ಮನೋಹರ ಲೋಹಿಯಾ]], [[ಶಾಂತವೇರಿ ಗೋಪಾಲಗೌಡ]] | influenced = | signature = | website = }} '''ಮೊಗೇರಿ ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ''' (೧೮.೨.೧೯೧೮–೧೪.೧೧.೧೯೯೨) ಆಧುನಿಕ ಕನ್ನಡ ಕವಿ. ಕೆಲವು ವ್ಯಾಖ್ಯಾನಕಾರೆರ್ ಅರೆನ್ "ಪೊಸ ಶೈಲಿದ" ಕಬಿತೆದ ಪ್ರವರ್ತಕೆ ಪಂಡ್ದ್ ಲೆಪ್ಪುವೆರ್. <ref>https://web.archive.org/web/20090228045107/http://www.hinduonnet.com/thehindu/mp/2002/09/26/stories/2002092600660200.htm The Hindu - 26 September 2002</ref> ==ಜೀವನ ಚರಿತ್ರೆ== ಆರ್ [[ಕರ್ನಾಟಕ]] ರಾಜ್ಯದ [[ಉಡುಪಿ]] ಜಿಲ್ಲೆದ ಕರಾವಳಿ ಗ್ರಾಮ ಮೊಗೇರಿಡ್ ಪುಟ್ಟಿಯೆರ್. ಪ್ರಾಥಮಿಕ ಶಿಕ್ಷಣ ಮೊಗೇರಿ ಬೊಕ್ಕ [[ಬೈಂದೂರು]]ಡ್ ಮುಗಿದ್ ಕುಂದಾಪುರೊಡು ಪ್ರೌಢಶಾಲೆಗ್ ಪೋಯೆರ್.<ref>{{Cite web|title=Gopalakrishna Adiga Biography - Biography of Gopalakrishna Adiga|url=https://www.poemhunter.com/gopalakrishna-adiga/biography/|access-date=2022-01-22|website=Poem Hunter|language=en-us}}</ref> ''ಸಾಕ್ಷಿ'' ಪತ್ರಿಕೆದ ಸಂಪಾದಕೆರಾದ್ ಆರ್ ಕನ್ನಡ ಸಾಹಿತ್ಯನ್ ಜನಸಾಮಾನ್ಯೆರೆಗ್ ಕನಯೆರೆ ಸಹಾಯ ಮಲ್ತೆರ್.<ref name="hin3">{{usurped|[https://web.archive.org/web/20070313181327/http://www.hinduonnet.com/thehindu/2004/10/04/stories/2004100411610300.htm Gopalakrishna Adiga remembered]}} The Hindu - 4 October 2004</ref> ಅಡಿಗಾನ ಮಗೆ ಮನು ರಾಜು, ಸಿಎನ್ಎನ್ ದ ಹಿರಿಯ ರಾಜಕೀಯ ವರದಿಗಾರೆರ್.<ref>{{Cite web | url=http://www.cnn.com/profiles/manu-raju | title=CNN Profiles - Manu Raju - Chief Congressional Correspondent | website=[[CNN]] }}</ref> ಬೊಕ್ಕೊಂಜಿ ಮಗೆ, ಶರತ್ ರಾಜು, ಅಮೇರಿಕೊಡು ಒರಿ ಚಿತ್ರ ನಿರ್ದೇಶಕೆರ್. ==ವಿದ್ಯಾಭ್ಯಾಸ ಬೊಕ್ಕ ವೃತ್ತಿ== === ವಿದ್ಯಾಬ್ಯಾಸೊ === *ಅಡಿಗೆರ್ ಪ್ರಾಥಮಿಕ ಮೊಗೇರಿಡ್ ಬುಕ್ಕೊ ಪ್ರೌಢ ಶಿಕ್ಷಣೊನು ಬೈಂದೂರುಡ್ ಮಲ್ತೆರ್. *ಉನ್ನತ ಶಿಕ್ಷಣೊಗು ಆರ್ ಮೈಸೂರುದ ಮಹಾರಾಜ ಕಾಲೇಜಗ್ ಸೇರ್‌ಯೆರ್. ಇಂಗ್ಲೀಸ್‌ನ್ ಮುಕ್ಯೊ ವಿಸಯೊ ಆದ್ ದೆತೊಂದು ಐತ ಬಗೆಟ್ ಜಾಸ್ತಿ ಅಧ್ಯಯನೊ ಮಲ್ತ್‌ದ ಮೈಸೂರು ವಿಶ್ವವಿದ್ಯಾಲಯೊಡ್ದ್ ಬಿ.ಎ. ಆನರ್ಸ್ ಪದವಿನ್ ಪಡೆಯೆರ್‍. *ನಾಗ್ಪುರೊ ವಿಶ್ವವಿದ್ಯಾನಿಲಯೊಡ್ ಇಂಗ್ಲಿಸ್ ಎಂ.ಎ. ಪದವಿ ಪಡೆಯೆರ್. ===ವೃತ್ತಿ=== *ಮೈಸೂರು ಶಾರದ ಕಾಲೇಜುಡ್ ಇಂಗ್ಲೀಸ್‍ಡ್ ಉಪನ್ಯಾಸಕರಾದ್ ಸೇವೆ ಮಲ್ತ್‌ದೆರ್.<ref name="hin2">[https://web.archive.org/web/20040823112054/http://www.hindu.com/mag/2004/04/25/stories/2004042500260300.htm The Mysore generation] ''The Hindu'' - 25 Apr 2004.</ref> *ಸಂತ ಫಿಲೋಮಿನ ಕಾಲೇಜಿಡ್‍ ಪತ್ತ್ ವರ್ಸೊ ಸೇವೆ ಮಲ್ತೆ‌ರ್. *1960ಡ್ ಸಾಗರೋದ ಲಾಲ್ ಬಹದ್ದೂರ್ ಶಾಸ್ತ್ರಿ ಕಾಲೇಜಿಡ್ ಪ್ರಾಂಶುಪಾಲೆರಾದ್ ಸೇವೆ ಮಲ್ತ್‌ದೆರ್. *ಉಡುಪಿದ ಪೂರ್ಣಪ್ರಜ್ಞಾ ಕಾಲೇಜಿಡ್‌ ಸೇವೆ ಮಲ್ತ್‌ದೆರ್. 1950 ಬೊಕ್ಕ 1960 ದಶಕೊಡು ಅಡಿಗ [[ಮೈಸೂರು]]ಡ್ ಶಿಕ್ಷಕೆರಾದಿತ್ತೆರ್. ೧೯೬೪ ಡ್ದ್ ೧೯೬೮ ಮುಟ್ಟ ಸಾಗರ ಡ್ ಲಾಲ್ ಬಹದ್ದೂರ್ ಕಾಲೇಜಿಡ್ ಪ್ರಿನ್ಸಿಪಾಲ್ ಆದಿತ್ತೆರ್, ೧೯೬೮ ಡ್ದ್ ೧೯೭೧ ಮುಟ್ಟ [[ಉಡುಪಿ]] ಡ್ ಪೂರ್ಣ ಪ್ರಜ್ಞ ಕಾಲೇಜಿಡ್ ಪ್ರಿನ್ಸಿಪಾಲ್ ಆದಿತ್ತೆರ್.<ref name="bio">{{cite web|url=http://geocities.com/indian_poets/kannada.html |title=Indian Poets Writing In Kannada |access-date=2010-10-08 |url-status=bot: unknown |archive-url=https://web.archive.org/web/20091026144559/http://geocities.com/indian_poets/kannada.html |archive-date=26 October 2009 }} - Indian Poets</ref> ಅರೆನ ಶೈಲಿನ್ 1947ಡ್ ಬ್ರಿಟಿಷ್ ಆಡಳಿತ ಡ್ದ್ ಭಾರತೀಯ ಸ್ವಾತಂತ್ರ್ಯ ಚಳುವಳಿಗ್ ಪ್ರತಿಕ್ರಿಯೆ ಆದ್ ವರ್ಣನೆ ಮಲ್ತೆರ್. ಆಧುನಿಕ ಪಾಶ್ಚಾತ್ಯ ಸಾಹಿತ್ಯ ಬೊಕ್ಕ ಭಾರತೀಯ ಸಂಪ್ರದಾಯೊಡ್ದ್ ಸ್ಫೂರ್ತಿ ಪಡೆಯಿನ ಆರ್ "ಕಾಲೊದ ಮೋಸ ಬೊಕ್ಕ ಆತಂಕೊನು" ಚಿತ್ರಣ ಮಲ್ಪೆರೆ ಸುರು ಮಲ್ತೆರ್.<ref name="bio" /> ==ಕೆಲಸ ಮಲ್ಪುಂಡು== *''ಭವತರಂಗ'' - ೧೯೪೬ *''ಅನಾಥೆ'' - ೧೯೫೪ (ಕಾದಂಬರಿ) *''ಭೂಮಿ ಗೀತೆ'' - ೧೯೫೯ *''ಮಣ್ಣಿನ ವಾಸನೆ'' (ಪ್ರಬಂಧದ ಗ್ರಂಥ) - ೧೯೬೬ *''ವರ್ಧಮಾನ'' - ೧೯೭೨ *''ಇದಣ್ಣ ಬಯಸಿರಲಿಲ್ಲ'' (ಕವನೊಲು) - ೧೯೭೫ *''ಸಾಮಗ್ರ ಕಾವ್ಯ'' (ಕವನ ಸಂಕಲನ) - ೧೯೭೬ *''[https://web.archive.org/web/20090612035606/http://www.sirinudi.org/ಸಾಕ್ಷಿ/ಸಾಕ್ಷಿ.html] ಸಾಕ್ಷಿ'' (ಪತ್ರಿಕೆ) - ೧೯೬೨ ==Quotes(ಹೇಳಿಕೆ)== *"ಇರುವುದೆಲ್ಲವ ಬಿಟ್ಟು ಇರದುದರೆಡೆಗೆ ತುಡಿವುದೆ ಜೀವನ?" Is life leaving everything we have and craving for things which we do not have? *"ಮೌನ ತಬ್ಬಿತು ನೆಲವ"<ref>{{usurped|1=[https://web.archive.org/web/20050216074048/http://www.caswath.com/about-quotes.htm QUOTES about Aswath]}} - C. Aswath</ref> === ಮರಣೊ === *೧೪ ನವಂಬರ್, ೧೯೯೨. == ಸಾಹಿತ್ಯ ಸೇವೆ == ಅಡಿಗೆರ್ ಕಬಿತೆ, ಕತೆ, ಕಾದಂಬರಿ, ಇಮರ್ಸೆ, ಪ್ರಬಂದೊಲೆನ್ ಬರೆತೆರ್. === ಕಬಿತೆಲೆನ ಕೋಪೆ === *ಭಾವತರಂಗ - ೧೯೪೬ *ಅನಂತೆ- ೧೯೫೪( ಕಾದಂಬರಿ ) *ಭೂಮಿ ಗೀತಾ - ೧೯೫೯ *ಮಣ್ಣಿನ ವಾಸನೆ( ಪ್ರಬಂಧಗಳ ಪುಸ್ತಕ ) - ೧೯೬೬ *ವರದಮಾನ-೧೯೭೨ *ಇದನ್ನು ಬಯಸಿರಲ್ಲಿಲಾ ( ಕವನಗಳು ) - ೧೯೭೨ *ಕೊರಗ ಕಾವ್ಯ ( ಕವಿತೆಗಳ ಸಂಗ್ರಹ ) - ೧೯೭೬ *ಸಾಕ್ಷಿ ( ಮ್ಯಾಗಜೀನ್ ) - ೧೯೬೨ *"ಇರುವುದೆಲ್ಲವ ಬಿಟ್ಟು ಇರದುದರೆಡೆಗೆ ತುಡಿವುದೆ ಜೀವನ " *ಮೌನ ತಬ್ಬಿತು ನೆಲವ " == ಅಡಿಗೆರೆಗ್ ಸಂದ್‍ನ ಪ್ರಶಸ್ತಿಲು == ೧೯೬೮ಡ್ ಅಡಿಗೆರೆಗ್ ೫೦ ಒರ್ಸೊ ದಿಂಜಿನ ಸಂದರ್ಬೊಡು ಉಡುಪಿಡ್ ಕು.ಶಿ.ಹರಿದಾಸ ಬಟ್ರ್ ಬುಕ್ಕೊ ವಿಜಯನಾಥ ಶೇಣೈಯೆರ್ ಇಂಚಿತಿ ಸಾಹಿತ್ಯಾಭಿಮಾನಿಲು ಒಂಜಿ ಅಪೂರ್ಪೊದ ಜಂಬರೊ ಲಕ್ಕವೆರ್. ಅಯಿಟ್ ಪೊಸ ಪೀಲಿಗೆದ ಮಹತ್ವೊದ ಕವಿ, ಸಾಹಿತಿ, ವಿಮರ್ಶಕೆರಾಯಿನ ಲಂಕೇಶ್, ಚಂದ್ರಶೇಖರ ಕಂಬಾರ, ಎಂ.ಜಿ. ಕೃಷ್ಣಮೂರ್ತಿ, ಶಾಂತಿನಾಥ ದೇಸಾಯಿ, ಜಿ. ಎಚ್. ನಾಯಕ, ಕಿ ರಂ. ನಾಗರಾಜ. ಗಿರಡ್ಡಿ ಗೋವಿಂದರಾಜ, ಬನ್ನಂಜೆ ಗೋವಿಂದಾಚರ್ಯ, ಡಿ. ಎಸ್. ರಾಯಕರ್ ಇಂಚಿನಕುಲು ಸೇರ್ದಿತ್ತೆರ. ವಿಮರ್ಶಕೆ '''ನಿಸ್ಸಿಂ ಇಝೆಕಿಲ್''' ಪನ್ಪಿನಾರ್ 'ಅಡಿಗೆರ್ ಕನ್ನಡೊಡು ಬರೆಪ್ಪುನ ಒರಿ ಮಲ್ಲ ಭಾರತೀಯ ಕವಿ' ಪಂಡ್‍ದ್ ಕೊಂಡಾಟೊ ಮಲ್ತೆರ್. #೧೯೭೪ಡ್ ರಾಜ್ಯೊ ಸಾಹಿತ್ಯ ಆಕಾಡೆಮಿ ಪ್ರಶಸ್ತಿ ಬತ್ತ್ಂಡ್. #೧೯೭೫ಡ್ ಅಡಿಗೆರೆಗ್ `ವರ್ಧಮಾನ'ಕವನೊ ಸಂಕಲನೊಗು ಕೇಂದ್ರ ಸಾಹಿತ್ಯ ಆಕಾಡೆಮಿ ಪ್ರಶಸ್ತಿ ಬತ್ತ್ಂಡ್. #೧೯೭೯ಡ್ [[ಕೇರಳ|ಕೇರಳೊ]]ದ ಪ್ರತಿಷ್ಠಿತೊ `ಕುಮಾರ್ ಸಮ್ಮಾನ್' ಪ್ರಶಸ್ತಿ ಲಬ್ಯೊ ಆಂಡ್. #೧೯೮೦ಡ್ `ಸಮಗ್ರ ಕಾವ್ಯೊ'ಗು ಮೂಡಬಿದ್ರೆದ `ವರ್ಧಮಾನ' ಪ್ರಶಸ್ತಿ ತಿಕ್ಂಡ್. #೧೯೮೨ಡ್ ಪ್ಯಾರಿಸ್, ಯುಗೋಸ್ಲಾವಿಯಡ್ ನಡತ್ತ್‌ನ ವಿಶ್ವಕವಿ ಸಮ್ಮೇಳನೊದ ಆಹ್ವಾನಿತೆರಾದ್ ಭಾಗವಹಿಸದೆರ್. #೧೯೮೬ಡ್ ಮಧ್ಯಪ್ರದೇಸೊದ ಸರಕಾರೊ ಆರಂಭಿಸಯಿನ ಸುರುತ `ಕಬೀರ್ ಸನ್ಮಾನ್' ಅಡಿಗೆರೆ ಪಾಲ್‍ಗ್ ಬತ್ತ್ಂಡ್. #೧೯೮೮ಡ್ ಥ್ಯಾಲಂಡ್‍ದ ಬ್ಯಾಂಕಾಕ್ ನಗರೊಡು ನಡತ್ತ್‌ನ ಜಾಗತಿಕ ಕವಿ ಸಮ್ಮೇಳನೊಡು 'ವರ್ಲ್ಡ್ ಅಕಾಡೆಮಿ ಆಫ್ ಆರ್ಟ್ ಎಂಡ್ ಕಲ್ಚರ್' ಸಂಸ್ಥೆ ಆರೆಗ್ 'ಡೊಕ್ಟರ್ ಆಫ್ ಲಿಟರೇಚರ್' ಪ್ರಶಸ್ತಿ ಕೊರ್‌ದ ಗೌರವಿಸಾಂಡ್. #'ರಾಜ್ಯೋತ್ಸವ ಪ್ರಶಸ್ತಿ' #'ಪಂಪ ಪ್ರಶಸ್ತಿ'. == ಉಲ್ಲೇಕೊಲು == {{Reflist}} [[ವರ್ಗೊ:ಕವಿ|ಗೋಪಾಲಕೃಷ್ಣ ಅಡಿಗ]] [[ವರ್ಗೊ:ವ್ಯಕ್ತಿಲು]] [[ವರ್ಗೊ:ಕನ್ನಡ ಕವಿ]] oga4o7bjq8rkpihiyd9bbq67zjzasj9 ಗಾಯತ್ರಿ ನಾವಡ 0 9716 362734 281060 2026-07-13T00:49:14Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362734 wikitext text/x-wiki ಗಾಯತ್ರೀ ನಾವಡೆರ್ ಸ್ತ್ರೀವಾದ, ಸಂಸ್ಕೃತಿ ವಿಮರ್ಶೆ, ಜಾನಪದ ಸ೦ಗ್ರಹ, ಅನುಭಾವ ಸಾಹಿತ್ಯ, ಬುಡಕಟ್ಟು ಅಧ್ಯಯನ ಇಂಚಿತ್ತ್ ಕ್ಷೇತ್ರೊಡು ಸಂಶೋಧಕಿಯಾದ್ ಬೆನ್‌ತಿನಾರ್. ಮೇರ್ ಕನ್ನಡ ಬುಕ್ಕೊ [[ತುಳು]] ಸಾಹಿತ್ಯ ಕ್ಷೇತ್ರೊಡು ಪ್ರಮುಖ ಪಾತ್ರ ಮೆರ್‌ನಲಾ ಉಂಡು.೧೯೭೫‌ಡ್ [[ಎ.ವಿ.ನಾವಡ|ಎ.ವಿ.ನಾವಾಡೆರ್]] ಮೆರೆನ ಬುಡೆತಿ. 'ಜೀವಿ' ಪನ್ಪಿನ ಕಾವ್ಯನಾಮೊಡು ಹೈಸ್ಕೂಲ್ ಬುಕ್ಕೊ ಕಾಲೇಜ್‌ಡ್ ಉಪ್ಪುನಗನೆ ಲೇಖನ, [[ಕಬಿತೆ|ಕವಿತೆಲೆನ್]] ಬರೆಯೊಂದು ಇತ್ತೆರ್. == ಜನನೊ == [[ಉಡುಪಿ]] ಜಿಲ್ಲೆದ ಕೋಟೇಶ್ವರ್‌ಡ್ ಅಗೊಸ್ಟ್ ೭,೧೯೫೪‌ಕ್ ಪುಟ್ಟಿಯೆರ್. ಅಮ್ಮೆರ್ ಕೃಷ್ಣವರ್ಣ ಕೋಟೇಶ್ವರ, ಅಪ್ಪೆ ಕಮಲಮ್ಮ. ನಾಲ್ ಜನ ಆನ್ ಬುಕ್ಕೊ ನಾಲ್ ಜನ ಪೊನ್ನು ಜೋಕ್ಲೆಡ್ ಕಡೆತಾರ್ ಗಾಯತ್ರೀ ನಾವಡೆರ್. == ಶಿಕ್ಷಣ == ಮೇರ್ ಬಿ.ಎ ಪದವಿದಾರೆರ್. ಬಿ.ಎ ಪದವಿ ಪಡೆದ್ ಆಯಿಬುಕ್ಕೊ೧೯೮೮ಡ್ ಧಾರವಾಡದ [[ಕರ್ನಾಟಕ]]ವಿಶ್ವವಿಧ್ಯಾಲಯಡ್ದ್ ಕನ್ನಡ ಸ್ನಾತಕೋತ್ತರ ಪದವಿ ಪಡೆಯೊಂಡೆರ್.'ಕರಾವಳಿ ಜನಪದ ಸಾಹಿತ್ಯದಲ್ಲಿ ಸ್ತ್ರೀವಾದಿ ನೆಲೆಗಳು' ಪನ್ಪಿನ ಮಹಾಪ್ರಬಂಧೊಗು ಗುಲ್ಬರ್ಗ ವಿಶ್ವವಿಧ್ಯಾಲಯಡ್ದ್ ಬುಕ್ಕೊ 'ಸಿರಿಪಂಥ: ಮಹಿಳಾ ಸಬಲೀಕರಣ - ಸಮಾಜೋ ಸಾಂಸ್ಕೃತಿಕ ಅಧ್ಯಯನ' ಮಹಾಪ್ರಬಂಧೊಗು ಮಣಿಪಾಲ ವಿಶ್ವವಿಧ್ಯಾಲಯಡ್ದ್ ಪಿ.ಎಚ್.ಡಿ ಪದವಿ ಪಡೆಯೊಂದೆರ್.<ref>ಚಂದ್ರಗಿರಿ ನಾಡೋಜ ಡಾ.ಸಾ.ರಾ. ಅಬೂಬಕ್ಕರ್ ಅಭಿನ೦ದನಾ ಗ್ರ೦ಥ, ಸ೦ಪಾದಕರು ಡಾ.ಸಬೀಹಾ, ಪ್ರಕಾಶಕರು ಸಿರಿವರ ಪ್ರಕಾಶನ ಬೆ೦ಗಳೂರು, ಪ್ರಥಮ ಮುದ್ರಣ, ೨೦೦೯ ಪುಟ ಸಂಖ್ಯೆ-೩೯೭</ref> == ಕೃತಿ == ಮೇರ್ ಮಹಾಪ್ರಬಂಧೊಲೆನ್, ಸ್ತ್ರೀವಾದ ವಿಮರ್ಶೆ, ಸಂಪಾದಿತ ಕೃತಿಕುಲೆನ್ ಬರೆತೆರ್. === ಮಹಾಪ್ರಬಂಧೊಲು === # ಕರಾವಳಿ ಜನಪದ ಸಾಹಿತ್ಯದಲ್ಲಿ ಸ್ತ್ರೀವಾದಿ ನೆಲೆಗಳು.<ref>http://udupibits.in/?p=1842{{Dead link|date=August 2021 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> # ಸಿರಿಪ೦ಥ:ಮಹಿಳಾ ಸಬಲೀಕರಣ -ಸಮಾಜೋ ಸಾ೦ಸೃತಿಕ ಅಧ್ಯಯನ === ಸ್ತ್ರೀವಾದ ವಿಮರ್ಶೆ ಕೃತಿ === # ವಿರಚನೆ - ೧೯೯೭ # ಭಾರತೀಯ ಸ್ತ್ರೀವಾದ: ಒಂದು ಸಂಕಥನ - ೨೦೦೦ # ಮಹಿಳಾ ಸಂಕಥನ - ೨೦೦೩ # ಸಿರಿಪಂಥ: ಮಹಿಳಾ ಸಾಂಸ್ಕೃತಿಕ ಸಬಲೀಕರಣದ ಮಾದರಿ # ನಮ್ಮ ಹೆಣ್ಣುಮಗು<ref>{{Cite web |url=https://www.bookbrahma.com/author/gayatri-navada |title=Archive copy |accessdate=2020-03-31 |archivedate=2024-12-15 |archive-url=https://web.archive.org/web/20241215181144/https://www.bookbrahma.com/author/gayatri-navada |url-status=dead }}</ref> === ಸಂಪಾದಿತ ಕೃತಿ === # ಮೂಕಜ್ಜಿ ಬದುಕು ಸಾಹಿತ್ಯ - ೧೯೮೮ # ಕಾಡ್ಯನಾಟ: ಪಠ್ಯ ಮತ್ತು ಪ್ರದರ್ಶನ - ೧೯೯೨ # ತೇರು -೧೯೯೩ # ಸಾವಿರ ಕೀರ್ತನೆಗಳು - ೨೦೦೦ # ಅಲೆಯೊಸಗೆ - ೨೦೦೧ # ಕರಾವಳಿಯ ಜನಪದ ಕತೆಗಳು # ಕರಾವಳಿ ಮದುವೆ ಹಾಡುಗಳು === ಬೇತೆ ಕೃತಿಕುಲು === # ಚಿತ್ತಾರ ಬರೆದ ಬದುಕು ೧೯೯೧ # ನಮ್ಮ ಹೆಣ್ಣು ಮಗು ೧೯೯೨ # ಭಾರತೀಯ ಸ್ತ್ರೀವಾದ:ಒ೦ದು ಸ೦ಕಥನ # ಕಾದ೦ಬರಿ-ಅಲೈ ಓಶೈ # ಸಿರಿಕತೆ ೧೯೯೪ # ಸಾಮೂಹಿಕ ವಿವಾಹ:ಒಂದು ಸಾಮಾಜಿಕ ಅಧ್ಯಯನ - ೧೯೯೨ == ಸಂಶೋಧನೆದ ಯೋಜನೆಲು == ಖಾರ್ವಿ ಸಮುದಾಯ ಆರ್ಥಿಕ - ಸಾಮಾಜಿಕ ಅಧ್ಯಯನ ಕುಡುಬಿಯರು, ಕಾಡ್ಯನಾಟ, ಪಾಣರಾಟ, ಕೋಟ ಪರಿಸರದ ಜೀವನಾವರ್ತನೆಗ್ ಸಂಬಂಧಿ ಆಚರಣಾತ್ಮಕ ಪದ್ಯೊಲು, ಸಾಕ್ಷ್ಯಚಿತ್ರ ನಿರ್ದೇಶನ, ಪನ್ಪಿನ ಸಂಶೋಧನೆದ ಯೋಜನೆಲೆನ್ ಮಲ್ದೆರ್. == ಸ್ಥಾನೊಲು == * ೧೯೯೨ ಮಹಿಳಾನಿಷ್ಠ ಜಾನಪದ ಕಾರ್ಯಗಾರ, ಧರ್ಮಸ್ಥಳಡ್ ನಡೆತಿನ ಮಹಿಳಾ ಜಾನಪದ ಕಲೆತ ತರಬೇತಿಡ್ ಕಾರ್ಯಗಾರ ಸಂಚಾಲಕಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಣೆ ಮಲ್ದೆರ್. * ಸ್ತ್ರೀಸ್ವಾಸ್ಥ್ಯಕಾರ್ಯಗಾರದ ನಿರ್ದೇಶಕಿಯಾದ್ ಕಾರ್ಯನಿರ್ವಹಣೆ. * ಕುಂದಾಪುರದ ಸ್ಪಂದನ ಸಾಹಿತ್ಯಿಕ ಸಾಮಾಜಿಕ ವೇದಿಕೆದ ಸ್ಥಾಪಕ ಕಾರ್ಯದರ್ಶಿ. * ಕುಂದಾಪುರದ ಪ್ರಾದೇಶಿಕ ವ್ಯಾಸಾಂಗದ ಪ್ರಕಾಶಕಿ. *ಕರಾವಳಿ ಲೇಖಕಿ ಬುಕ್ಕೊ ವಾಚಕಿಯರೆನ ಸಂಘ ಕುಂದಾಪುರ ತಾಲೂಕುದ ಪ್ರತಿನಿಧಿ. == ಪ್ರಶಸ್ತಿಲು == * 'ಮೂಕಜ್ಜಿ ಬದುಕು ಸಾಹಿತ್ಯ' ಕೃತಿಗ್ ಮಂಗಳೂರು ವಿಶ್ವವಿದ್ಯಾನಿಲಯಡ್ದ್ ಪೀಟರ್ ಜೆ.ಕ್ಲಾಸ್ 'ಮಹಿಳಾ ಜಾನಪದ ಪ್ರಶಸ್ತಿ'. * 'ಚಿತ್ತಾರ ಬರೆದ ಬದುಕು' ಕೃತಿಗ್ ೧೯೯೦ಡ್ ಕರ್ನಾಟಕ ಜಾನಪದ ಬುಕ್ಕೊ ಯಕ್ಷಗಾನ ಅಕಾಡೆಮಿಡ್ದ್ 'ಉತ್ತಮ ಕೃತಿ' ಇನಾಮು. * ೧೯೯೨ಡ್ ಲೋಕ ಶಿಕ್ಷಣ ನಿರ್ದೇಶನಾಲಯ ಪುರಸ್ಕಾರ. * ೧೯೯೪ಡ್ 'ಕಾಡ್ಯನಾಟ: ಪಠ್ಯ ಮತ್ತು ಪ್ರದರ್ಶನ' ಗ್ರಂಥಗ್ ಆರ್ಯಭಟ ಪ್ರಶಸ್ತಿ. * ೧೯೯೪ಡ್ ಕಾಂತಾವರ ಕನ್ನಡ ಸಂಘಡ್ದ್ 'ಸಂಸ್ಕೃತಿ ಸಂಶೋಧಕಿ' ಪುರಸ್ಕಾರ. * ೧೯೯೩ಡ್ 'ಕಾಡ್ಯನಾಟ: ಪಠ್ಯ ಮತ್ತು ಪ್ರದರ್ಶನ' ಗ್ರಂಥಗ್ ಗು೦ಡ್ಮಿ ಜಾನಪದ ಪ್ರಶಸ್ತಿ. * ವೀರ ರಾಣಿ ಅಬ್ಬಕ್ಕ ಪ್ರಶಸ್ತಿ.<ref>https://vijaykarnataka.com/news/mangaluru/-/articleshow/29827652.cms</ref> * ಕುಸುಮಶ್ರೀ ಪ್ರಶಸ್ತಿ.<ref>{{Cite web |title=Archive copy |url=https://kundapraa.com/kusumashree-award-to-av-navada-and-dr-gayathri-navada/ |access-date=2020-03-31 |archive-date=2017-12-24 |archive-url=https://web.archive.org/web/20171224094413/http://kundapraa.com/kusumashree-award-to-av-navada-and-dr-gayathri-navada/ |url-status=dead }}</ref> * ಶಾಶ್ವತೀ ಸದೋದಿತಾ ಪ್ರಶಸ್ತಿ. == ಉಲ್ಲೇಕೊಲು == {{Reflist}} [[ವರ್ಗೊ:ಲೇಖಕೆರ್]] [[ವರ್ಗೊ:ವಿಕಿ ಲವ್ಸ್ ವಿಮೆನ್ ಸೌತ್ ಏಶಿಯಾ - ೨೦೨೦]] 1jkk8regxfdz8ch33f2rxtnga45ln67 ಕೋಟಿ ಚೆನ್ನಯ (ಸಿನಿಮೊ) 0 13342 362717 283116 2026-07-12T15:01:46Z ChiK 1136 /* */ 362717 wikitext text/x-wiki {{Infobox film | name = ಕೋಟಿ ಚೆನ್ನಯ | image = | caption = | director = ಆನಂದ್ ಪಿ ರಾಜು | producer = ಆರ್ ಧನರಾಜ್ | screenplay = ಆನಂದ್ ಪಿ ರಾಜು<br />ಡಾ. ವಾಮನ್ ನಂದಾವರ<br />ಸುಧಾಕರ್ ಬನ್ನಂಜೆ | story = ಆರ್ ಧನರಾಜ್ | based_on = [[ಕೋಟಿ ಚೆನ್ನಯ]] | starring = ಬಾಲಕೃಷ್ಣ ಶೆಟ್ಟಿ<br />ಶೇಖರ್ ಕೋಟ್ಯಾನ್<br />[[ವಿನಯಾ ಪ್ರಸಾದ್]]<br />[[ನೀತು]] | music = [[ವಿ. ಮನೋಹರ್]] | cinematography = | editing = | studio = ಪ್ರಾರ್ಥನಾ ಕ್ರಿಯೇಷನ್ಸ್ | distributor = | released = {{Film date|2007|||[[ಭಾರತ]]}} | runtime = | country = [[ಭಾರತ]] | language = [[ತುಳು ಭಾಷೆ|ತುಳು]] | budget = | gross = }} '''ಕೋಟಿ ಚೆನ್ನಯ ಚಿತ್ರ''' ತುಳು ಚಿತ್ರರಂಗೊದ ಚಿತ್ರ. 1973ಡ್ ಚಿತ್ರ ಬಿಡುಗಡೆ ಆತ್ತನ್ಡ್.<ref>{{cite news|title=Koti Chennaya (1973) Tulu movie: Cast & Crew|url=https://chiloka.com/movie/koti-chennaya-1973#movie_crew_list|work=chiloka.com}}</ref> ಉಂದು ಚಿತ್ರ ತುಳು ನಾಡ್ದ ಕಾರ್ಣಿಕ ಪುರುಷೆರ್ನ ಕಥೆ. ಜೋತಿ ಚಿತ್ರ ಮಂದಿರೊಡ್ 150 ದಿನ ಬುಕ್ಕೊ ಅಲಂಕಾರ್ ಚಿತ್ರಮಂದಿರೊಡ್ 125 ದಿನ ಚಿತ್ರ ಪ್ರದರ್ಶನ ಆತ್ತನ್ಡ್.<ref>{{cite news|title=Mangaluru: Coastalwood enthralling moviegoers since time immemorial|url=https://www.daijiworld.com/news/newsDisplay.aspx?newsID=706971|work=www.daijiworld.com|language=en}}</ref> == ಚಿತ್ರೊದ ತಾಂತ್ರಿಕ ವಿಷಯೊಲು == ನಿರ್ದೇಶನ - ವಿಷ್ಣು ಕುಮಾರ್ ನಿರ್ಮಾಪಕೆ - ಮುದ್ದು ಸುವರ್ಣ ಕಥೆ - ಬಿ.ಎ.ವಿವೇಕ್ ರೈ ಸಂಗೀತಗಾರೆ - ಪಿ.ಬಿ.ಶ್ರೀನಿವಾಸ್ == ಕಲಾವಿದೆರ್ == ಶುಭಾಷ್ ಚಂದ್ರ ಪಡಿವಾಳ್ ಕೋಟಿನ ಪಾತ್ರ ಬುಕ್ಕೊ ವಮನ್ ರಾಜ್ ಚೆನ್ನಯನ ಪಾತ್ರ ಮಲ್ದೆರ್. == ಉಲ್ಲೇಕೊಲು == {{Reflist}} [[ವರ್ಗೊ:ತುಳು ಸಿನಿಮೊ]] [[ವರ್ಗೊ:ತುಳು ಚಿತ್ರ ನಟೆರ್]] [[ವರ್ಗೊ:ಸಿನೆಮಾ]] oiijiv17qyhmde29sbyaca0izbg1mx8 ಕುಕ್ಕುದ ಉಪ್ಪಡ್ 0 16101 362733 357544 2026-07-13T00:28:42Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362733 wikitext text/x-wiki [[ಕುಕ್ಕು|ಕುಕ್ಕುನು]] ಉಪಯೋಗ ಮಲ್ತ್‌ದ್ ಮಲ್ಪುನ ಉಪ್ಪಡ್‌ನ್ '''ಕುಕ್ಕುದ ಉಪ್ಪಡ್''' ಪಂಡ್ದ್ ಪನ್ಪೇರ್. ಉಂದು ಯೇತ್ ಸಮಯೋಗ್ಲಾ ದೀಯೊಲಿ. ಗಂಜಿದ ಒಟ್ಟುಗು ಉನಿಯೆರೆ ಉಂದು ಬಾರಿ ಲಾಯ್ಕ್ ಆಪುಂಡು. ಕುಕ್ಕುದ ಉಪ್ಪಡ್‌ಡ್ ಬೇತೆ ಬೇತೆ ವಿಧಾನ ಉಂಡು. ''ಕುಕ್ಕುದ ಉಪ್ಪಡ್''' ][ಕುಕ್ಕು] ನ್ ಉಪಯೋಗಿಸಾದ್ ಮಸ್ತ್ ಬಗೆತ ಉಪ್ಪಡ್ ಮನ್ಪುವೇರ್. ಉಂದು [[ದಕ್ಷಿಣ ಭಾರತ|ದಕ್ಷಿಣ]] ಬುಕ್ಕೊ ಆಗ್ನೇಯ ಏಷ್ಯಾಡ್ ಲಾ ಮಸ್ತ್ ಜನಪ್ರಿಯವಾದುಂಡು. [[File:Mango pickle. jpg.jpg|thumb|ಕುಕ್ಕುದ ಉಪ್ಪಡ್]] == ಇತಿಹಾಸೊ == ಕುಕ್ಕುದ ಉಪ್ಪಡ್‌ಗ್ ಸಾವಿರಾರು ವರ್ಸೊದ ಇತಿಹಾಸ ಉಂಡು. [[ಕ್ರಿಸ್ತ ಶಕ|ಕ್ರಿಸ್ತಶಕ]] ೧೬೦೦ [[ಕನ್ನಡ|ಕನ್ನಡದ]] ಕವಿ [[ಅಣ್ಣಾಜಿ|ಅಣ್ಣಾಜಿಯು]] ಅರೆನ ಸೌಂದರ್ಯ ವಿಲಾಸೊಡು ಕುಕ್ಕುದ ಮುಡಿಟ್ ಮಂದಿನ ಉಪ್ಪಡ್ ದ ಉಲ್ಲೇಕೊ ಉಂಡು.<ref>[https://economictimes.indiatimes.com/magazines/panache/mango-pickle-a-childhood-memory-with-its-many-avatars/articleshow/58662497.cms ಇಕೊನೋಮಿಕ್ಸ್ ಟೈಮ್ಸ್]</ref> == ವಿಧೊಲು== ಭಾರತೊಡು [[ಉಪ್ಪಡ್]] ಮನ್ಪುನ ಪ್ರಕ್ರಿಯೆ ಬೇತೆ ಪ್ರದೇಶೊದಕಲೆನ ಲೆಕ್ಕ ಅತ್ತ್. ಕುಕ್ಕುನ್ ತುಂಡು ತುಂಡು ಮಂತುದು ಅಥಾವೊ ಕುಕ್ಕುದ ಮುಡಿಲೆನ್ [[ಉಪ್ಪು (ಖಾದ್ಯ)|ಉಪ್ಪುದ]] ಒಟ್ಟುಗು ಗಾಳಿ ಪೋವಂದಿನ ಭರಣಿಡ್ ಮಸ್ತ್ ಸಮಯ ದೀದ್, ಬುಕ್ಕೊ ಮಸಾಲೆ ಪಾಡುದು ಉಪ್ಪಡ್ ಮನ್ಪುನು. ಉಪ್ಪಡ್ ಭಾರತೊಡು ಒಂಜಿ ವಿಶೇಷವಾಯಿನ ಪದಾರ್ಥ ಆದು, ಉಂದೆನ್ ವಿವಿಧ ಬಗೆತೊ ತರಕಾರಿಲೆನ್ ಉಪಯೋಗ ಮಂತುದು ಮನ್ಪುವೇರ್.<ref>[https://vijaykarnataka.com/lavalavk/food/about-easy-made-pickles/articleshow/59066269.cms ವಿಜಯ ಕರ್ನಾಟಕ ವರದಿ]</ref> ಅಯಿಟುಲಾ ಕುಕ್ಕುದ ಮುಡಿತ ಉಪ್ಪಡ್ ಮಸ್ತ್ ಜನಪ್ರಿಯ ಆದುಂಡು. ವಿವಿಧೊ ಪ್ರದೇಶೊಲು ಬುಕ್ಕೊ ಮಸಾಲೆ ವಿಧಾನಕು ಅನುಗುಣವಾದ್ ಅವೇತೊ ಅತ್ತ್ ಬಗೆ ಬಗೆತ ಕುಕ್ಕುದ ಉಪ್ಪಡ್ ಲು ಉಂಡು. ಅಯಿಟ್ ರಡ್ಡ್ ಬಗೆತ ಮಸ್ತ್ ಜನಪ್ರೀಯವಾಯಿನವು. *ಕುಕ್ಕುದ ಮುಡಿತ ಉಪ್ಪಡ್. *ತುಂಡು ತುಂಡು ಮಂತುದು ಮನ್ಪುನ ಉಪ್ಪಡ್. ಉಂದೇಟ್ ಕುಕ್ಕುದ ಮುಡಿತ ಉಪ್ಪಡ್ ಇಡೀ ದಕ್ಷಿಣ ಭಾರತೊಡು ಜನಪ್ರಿಯ ಆದುಂಡು. ಉಪ್ಪಡ್ ಮನ್ಪರೆನೇ ಪಂದ್ ಕೆಲವು ನಿರ್ದಿಷ್ಟವಾಯಿನ ವಿಶೇಷಾಯಿನ ಬಗೆ ಬಗೆತ ಕುಕ್ಕುಲು ಉಲ್ಲಾ. ಉಪ್ಪಡ್ ನ್ ಉಪ್ಪು, ಎಣ್ಣೆ ಬುಕ್ಕೊ ಮಸಾಲೆದ ಮಿಶ್ರಣೊನು ಗಳಿಸಾದ್ ಒಂಜಿ ನಿರ್ದಿಷ್ಟವಾಯಿನ ಪ್ರಕ್ರಿಯೆದ ಮೂಲಕ, ಅವೇತೋ ವರ್ಷ ಹಾಳ್ ಆವಂದಿ ಲೆಕ್ಕ ಉಪ್ಪಡ್ ನ್ ತಯಾರು ಮನ್ಪುವೆರ್.<ref>[https://vijaykarnataka.com/lavalavk/food/mango-pickle-varieties-of-karnataka/articleshow/69072082.cms ವಿಜಯಕರ್ನಾಟಕ ವರದಿ]</ref> === ಕುಕ್ಕುದ ಮುಡಿತ (ಅಪ್ಪೆ ಮಿಡಿ) ಉಪ್ಪಡ್ === ಕಿನ್ಯ ಕಿನ್ಯ ಕುಕ್ಕುದ ಮುಡಿಲೆನ್ ಸಂಗ್ರಹ ಮಂತುದು ಮನ್ಪುನ ಉಪ್ಪಡ್ ನ್ ಕುಕ್ಕುದ ಮುಡಿತ (ಅಪ್ಪೆ ಮಿಡಿ) ಉಪ್ಪಡ್ ಪಂದ್ ಪನ್ಪೇರ್. [[ಅಪ್ಪೆ ಮಿಡಿ]] ಪಂದೇ ಜನಪ್ರಿಯವಾದುಪ್ಪುನ, ಉಪ್ಪಡ್ ಪಂದೇ ಉಪಯೋಗ ಮನ್ಪುನ ಕುಕ್ಕುಲು ಉಲ್ಲ. ಉಂದು ಬಾರೀ ಪರಿಮಳ ಬುಕ್ಕೊ ಮಸ್ತ್ ರುಚಿಲಾ. ಅಂಚಾದ್ ಉಪ್ಪಡ್ ಗ್ ಬಾರೀ ಎಡ್ಡೆ. [[File:Kadumanga Mango pickle from Kerala India.jpg|thumb|'''ಕುಕ್ಕುದ ಮುಡಿತ ಉಪ್ಪಡ್''']] [[File:APPEMIDI1.jpg|thumb|'''ಅಪ್ಪೆಮಿಡಿ''']] ===ತುಂಡು ತುಂಡು ಮಂತುದು ಮನ್ಪುನ ಉಪ್ಪಡ್ === ಉಂದೆನ್ ಕಸಿ ಕುಕ್ಕುಡ್ ಹೆಚ್ಚಾದು ಮನ್ಪುವೇರ್. ಮಲ್ಲ ಮಲ್ಲ ಕುಕ್ಕುಲೆನ್ ತುಂಡು ಮಂತುದು ಮನ್ಪುನ ಉಪ್ಪಡ್‌ಗ್ ಉಪಯೋಗಿಸುವೆರ್.<ref>{{Cite web |url=https://food.ndtv.com/food-drinks/7-lip-smacking-south-indian-pickles-you-need-to-try-1662259 |title=ಎನ್‍ಡಿಟಿವಿ |accessdate=2024-08-03 |archivedate=2024-08-03 |archive-url=https://web.archive.org/web/20240803105010/https://food.ndtv.com/food-drinks/7-lip-smacking-south-indian-pickles-you-need-to-try-1662259 |url-status=dead }}</ref> ದಕ್ಷಿಣ ಭಾರತೊಡು, ಉಪ್ಪಡ್ ಉಪ್ಪಂದಿನ ಇಲ್ಲ್ ಉಪ್ಪಂದ್. ಅಂಚನೇ ಒವ್ವೇ ಒಂಜಿ ಸಮಾರಂಭೊಲು ಆವಾಡ್ ಅನ್ನದಾನದಲ್ಪ ಸುರುಕಾದ್ ಇರೆತ ಕೊಡಿಗ್ ಬಲಸುನೇ ಉಪ್ಪಡ್. [[File:Indian Mango Pickles.JPG|thumb|'''ತುಂಡು ತುಂಡು ಮಂತುದು ಮನ್ಪುನ ಕುಕ್ಕುದ ಉಪ್ಪಡ್''']] == ಪಿದಾಯಿದ ಕೊಂಡಿ == # https://web.archive.org/web/20240803115019/https://h2g2.com/edited_entry/A3100168 == ಉಲ್ಲೇಕೊಲು == {{Reflist}} {{Reflist}} {{ತುಳುವೆರೆ ತೆನಸ್ಸ್}} [[ವರ್ಗೊ:ತುಳುನಾಡ್]] [[ವರ್ಗೊ:ತಿನಿಸುಲು]] [[ವರ್ಗೊ:ತುಳುವೆರೆ ಆಟಿ ತಿಂಗೊಲು]] mq0cpjuc1odyyr6giyi4s3d2x3hzubr ಫರೀದಾ ಯಾಸ್ಮಿನ್ 0 18511 362738 354116 2026-07-13T01:56:48Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362738 wikitext text/x-wiki {{ವಿಕಿಪೀಡಿಯ ಏಷ್ಯನ್ ತಿಂಗೊಲು 2024}} {{Infobox officeholder | name = '''ಫರೀದಾ ಯಾಸ್ಮಿನ್''' | native_name_lang = bn | image = Farida Yasmin (9).jpg | caption = 2018 ಟ್ ಯಾಸ್ಮಿನ್, <br/>ಬಾಂಗ್ಲಾದೇಶೊದ ಸಂಸತ್ತುದ ಸದಸ್ಯೆ ಪೊಂಜೊವುಲೆನ ಮೀಸಲು ಸ್ಥಾನೊ-35 | parliament = ಬಾಂಗ್ಲಾದೇಶ | term_start = 28 ಫೆಬ್ರುವರಿ 2024 | term_end = 6 ಆಗಸ್ಟ್ 2024 | birth_name = ಫರೀದಾ ಯಾಸ್ಮಿನ್ ಬುಲ್ಬುಲ್ | birth_date = {{birth date and age|1963|06|01|df=y}} | birth_place = ನರಸಿಂಗ್ಡಿ, ಪೂರ್ವ ಪಾಕಿಸ್ತಾನ, ಪಾಕಿಸ್ತಾನ | alma_mater = ಢಾಕಾ ವಿಶ್ವವಿದ್ಯಾಲಯ | occupation = ಪತ್ರಕರ್ತರ್ ಬುಕ್ಕೊ ಸಂಪಾದಕೆರ್ | known_for = her tenure senior sub-editor of ''[[The Daily Ittefaq]]'' and joint secretary of [[National Press Club (Bangladesh)|Bangladesh National Press Club]]<ref>{{cite news |title=Saiful Islam Talukder's contribution recalled |url=http://bssnews.net/newsDetails.php?cat=0&id=480594$date=2015-03-24&dateCurrent=2015-03-27 |url-status=dead |work=Bangladesh Sangbad Sangstha |date=24 March 2015 |archive-url=https://web.archive.org/web/20161118224217/http://bssnews.net/newsDetails.php?cat=0&id=480594$date=2015-03-24&dateCurrent=2015-03-27 |archive-date=18 November 2016 |access-date=18 November 2016}}</ref><ref>{{cite web |title=Fruit festival at Press Club |url=http://websbd.net/news/fruit-festival-at-press-club/ |website=websbd.net |access-date=18 November 2016}}</ref> | spouse = {{marriage|ನಮ್ ನಿಜಾಮ್|1990}} | children = 2 | awards = ವಿಮೆನ್ ಲೀಡ್ ರಾಷ್ಟ್ರ ಪ್ರಶಸ್ತಿ, ಬಾಂಗ್ಲಾದೇಶ ಮಹಿಳಾ ಪರಿಷತ್ ಪ್ರಶಸ್ತಿ | signature = Farida Yasmin signature.jpg }} '''ಫರೀದಾ ಯಾಸ್ಮಿನ್''' (ಜನನೊ 1 ಜೂನ್ 1963) <ref>{{cite web|url=https://www.parliament.gov.bd/member-profile/012033501/farida-yasmin|title=Member profile|accessdate=2024-11-29|publisher=Government of Bangladesh}}{{Dead link|date=March 2026 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> [[ಬಾಂಗ್ಲಾದೇಶ]]ದ ಪತ್ರಕರ್ತೆರ್, ಬುಕ್ಕೊ ಜತಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್ ದ ಮಾಜಿ ಅಧ್ಯಕ್ಷೆರ್.<ref>{{cite news |title=Social Afforestation Improves Environ, Eradicates Poverty |url=https://www.highbeam.com/doc/1P3-3021116621.html |url-status=dead |work=The New Nation |date=17 July 2013 |archive-url=https://web.archive.org/web/20180728002913/https://www.highbeam.com/doc/1P3-3021116621.html |archive-date=28 July 2018 |access-date=18 November 2016}}</ref><ref>{{cite web |title=30 female garment workers honoured |url=http://www.independent-bangladesh.com/200803163222/business/30-female-garment-workers-honoured.html |website=independent-bangladesh.com |publisher=Independent Bangladesh |access-date=18 November 2016 |archive-url=https://web.archive.org/web/20161119055920/http://www.independent-bangladesh.com/200803163222/business/30-female-garment-workers-honoured.html |archive-date=19 November 2016 |url-status=dead}}</ref><ref>{{Cite news |title=Farida, Elias elected as JPC president, secretary |url=https://www.newagebd.net/article/125875/farida-elias-elected-as-jpc-president-secretary |access-date=2020-12-31 |work=New Age |date=31 December 2020 |language=en |archive-date=2020-12-31 |archive-url=https://web.archive.org/web/20201231152746/https://www.newagebd.net/article/125875/farida-elias-elected-as-jpc-president-secretary |url-status=dead }}</ref> ಆರ್ ಜತಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್ ದ ಸುರುತ ಪೊಂಜೊವು ಅಧ್ಯಕ್ಷರಾದು ಇತ್ತೆರ್.<ref>{{cite news |title=Jatiya press club: Memberships of Farida, Shyamal ‘revoked’ |url=https://www.thedailystar.net/news/bangladesh/news/jatiya-press-club-memberships-farida-shyamal-revoked-3674961 |work=The Daily Star |date=12 August 2024 |language=en}}</ref> ರಡ್ಡ್ ಬಾರಿ ಪ್ರೆಸ್ ಕ್ಲಬ್ ದ ಅಧ್ಯಕ್ಷರಾದ್ ಆಯ್ಕೆಯಾಯಿನ ಮೇರ್ 2020 ಡ್ದು ಆಗಸ್ಟ್ 2024 ತ ಮುಟ್ಟ ಸ್ಥಾನೊನು ಅಲಂಕಾರ ಮಂತು ಇತ್ತೆರ್.<ref>{{cite news|url=https://www.dhakatribune.com/bangladesh/dhaka/354432/press-club-president-accuses-committee-members-of |title=Farida Yasmin, Shyamal Dutta accuse members of forcefully trying to take over National Press Club|work=[[Dhaka Tribune]]|date=11 August 2024}}</ref> ಆರ್ '''ದಿ ಡೈಲಿ ಇಟ್ಟೆಫಾಕ್ನ''' ದ ಮಾಜಿ ಹಿರಿಯೆ ಪತ್ರಕರ್ತೆ ಬುಕ್ಕೊ ನ್ಯಾಷನಲ್ ಪ್ರೆಸ್ ಕ್ಲಬ್ (ಬಾಂಗ್ಲಾದೇಶ) ದ ಮಾಜಿ ಪ್ರಧಾನ ಕಾರ್ಯದರ್ಶಿಯಾದು ಉಲ್ಲೆರ್.<ref name="qtyz">{{cite news |title=Journalist Farida Yasmin's father passes away |url=http://www.daily-sun.com/post/85471/Journalist-Farida-Yasmin%E2%80%99s-father-passes-away |work=Daily Sun |date=22 October 2015 |access-date=18 November 2016 |archive-date=19 November 2016 |archive-url=https://web.archive.org/web/20161119055112/http://www.daily-sun.com/post/85471/Journalist-Farida-Yasmin%E2%80%99s-father-passes-away |url-status=dead}}</ref><ref>{{cite news |title=Media can play big role |url=http://www.thedailystar.net/frontpage/media-can-play-big-role-94837 |work=The Daily Star |date=10 June 2015 |access-date=18 November 2016}}</ref> 2017 ಟ್, ಆರ್ ಬಾಂಗ್ಲಾದೇಶ ಪ್ರೆಸ್ ಕ್ಲಬ್ ದ ಸುರುತ ಪೊಂಜೊವು ಪ್ರಧಾನ ಕಾರ್ಯದರ್ಶಿಯಾದ್ ಆಯ್ಕೆ ಆತೇರ್.<ref name="bdn31Dec2016" /><ref>{{Cite news |url=https://www.thedailystar.net/city/shafique-farida-panel-sweeps-jatiya-press-club-polls-1338358 |title=Shafique-Farida panel sweeps Jatiya Press Club polls |newspaper=The Daily Star |date=31 December 2016 |access-date=5 January 2017}}</ref> ಆರ್ ಜತಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್ ದ ಮಾಜಿ ಜಂಟಿ ಕಾರ್ಯದರ್ಶಿ ಲಾ ಆದು ಇತ್ತೆರ್. == ಸುರುತ ಜೀವನ ಬುಕ್ಕೊ ಶಿಕ್ಷಣ == ಅರೆನ ಅಪ್ಪೆ '''ಶಖಾವರ್ ಹುಸೇನ್''' '''ಭುಯಿಯಾನ್''' ಬುಕ್ಕೊ ಅಮ್ಮೆರ್ '''ಜಹಾನಾರ ಹುಸೇನ್'''. ಮೇರ್ ನರಸಿಂಗಡಿದ ಶಿಬ್ಪುರ ಬಾಲಕಿಯೆರೆನ ಪ್ರೌಢಶಾಲೆದ ವಿದ್ಯಾರ್ಥಿನಿ. ಶಿಬ್ಪುರ್ ಬಾಲಕಿಯರ ಪ್ರೌಢಶಾಲೆಡ್ದ್ ಪ್ರೌಢಶಾಲೆದ ಪ್ರಮಾಣಪತ್ರ ಪರೀಕ್ಷೆಡ್ ಬುಕ್ಕೊ ಈಡನ್ ಮೊಹಿಲಾ ಕಾಲೇಜಿಡ್ದ್ ಉನ್ನತ ಪ್ರೌಢಶಾಲೆದ (ಶಾಲೆ) ಪ್ರಮಾಣಪತ್ರ ಪರೀಕ್ಷೆಡ್ ಉತ್ತೀರ್ಣರಾಯೆರ್. ಯಾಸ್ಮಿನ್ ಢಾಕಾ ವಿಶ್ವವಿದ್ಯಾಲಯೊಡ್ದ್ ಸ್ನಾತಕೋತ್ತರ ಪದವಿ ಪಡೆಯೆರ್.<ref>{{Cite news |url=https://www.dhakacourier.com.bd/news/Essays/tete-a-tete-with-farida-yasmin/680 |title=Tête-à-tête with Farida Yasmin |work=Dhaka Courier |date=19 October 2018 |access-date=30 December 2018}}</ref> == ವೃತ್ತಿಜೀವನ == ಯಾಸ್ಮಿನ್ 2011ಡ್ ಎನ್ ಪಿ ಸಿ ದ ಜಂಟಿ ಕಾರ್ಯದರ್ಶಿಯಾದ್ ಆಯ್ಕೆ ಆಯೆರ್.<ref>{{cite news |title=Sabuj elected press club president, Abdal GS |url=http://bdnews24.com/bangladesh/sabuj-elected-press-club-president-abdal-gs |work=bdnews24.com |date=31 December 2010 |access-date=18 November 2016}}</ref> ಬುಕ್ಕೊ 2012ಟ್ ಲಾ.<ref>{{cite news |title=Press Club poll: Sabuj, Abdal reelected president, secy |url=http://www.risingbd.com/english/Press_Club_poll_Sabuj_Abdal_reelected_president_secy/599 |work=risingbd.com |date=30 December 2012 |access-date=18 November 2016}}</ref><ref>{{cite news |title=JPC team leaves for Agartala today |work=The New Nation |url=https://www.highbeam.com/doc/1P3-2645470861.html |url-status=dead |date=28 April 2012 |archive-url=https://web.archive.org/web/20180418230231/https://www.highbeam.com/doc/1P3-2645470861.html |archive-date=18 April 2018 |access-date=18 November 2016}}</ref> ದಕ್ಷಿಣ ಏಷ್ಯಾದ ಮಹಿಳಾ ಮಾಧ್ಯಮ ವೇದಿಕೆದ ಜಂಟಿ ಕಾರ್ಯದರ್ಶಿ ಬುಕ್ಕೊ ವೇದಿಕೆದ ಸ್ಥಾಪಕ ಸದಸ್ಯೆ ಆದಿತ್ತೆರ್.<ref>{{cite news |title=New committee of SAWM formed |url=https://www.highbeam.com/doc/1P3-2009291831.html |url-status=dead |work=The New Nation |date=10 April 2010 |archive-url=https://web.archive.org/web/20180419053303/https://www.highbeam.com/doc/1P3-2009291831.html |archive-date=19 April 2018 |access-date=18 November 2016}}</ref><ref>{{cite news |title=South Asian women's forum formed |url=https://www.highbeam.com/doc/1P3-1668476301.html |url-status=dead |work=The New Nation |date=6 January 2009 |archive-url=https://web.archive.org/web/20180418230659/https://www.highbeam.com/doc/1P3-1668476301.html |archive-date=18 April 2018 |access-date=18 November 2016}}</ref> ಬಾಂಗ್ಲಾದೇಶೊಡು ಪೊಣ್ಣುಲೆಗ್ ಮದಿಮೆ 18 ವರ್ಸೊಡ್ ಆವೊಡು ಪನ್ಪಿನ ಬಗ್ಗೆಲಾ ಆರ್ ಬಾಸೆಂಡೆರ್.<ref>{{cite web |title=Majority for retaining girls' marriage age at 18 |url=http://www.hawker.com.bd/news_details.php?news_id=387140&news_category_id=21&val_lan= |website=hawker.com.bd |publisher=Hawker |access-date=18 November 2016 |archive-date=19 November 2016 |archive-url=https://web.archive.org/web/20161119055548/http://www.hawker.com.bd/news_details.php?news_id=387140&news_category_id=21&val_lan= |url-status=dead}}</ref> ಅರೆನ್ ದಿ ಡೈಲಿ ಇಟ್ಟೆಫಾಕ್ ಡ್ ಇನ್-ಚಾರ್ಜ್ ಆದ್ ವರ್ಗಾವಣೆ ಮಲ್ತೆರ್.<ref>{{Cite book |last1=Flatt |first1=Emma J. |url=https://books.google.com/books?id=BEvzDwAAQBAJ&dq=farida+yasmin&pg=PA55 |title=Voices On South Asia: Interdisciplinary Perspectives On Women's Status, Challenges And Futures |last2=Murali |first2=Vani Swarupa |last3=Tieri |first3=Silvia |date=2020-06-24 |publisher=World Scientific |isbn=978-981-12-1327-4 |pages=55 |language=en}}</ref> 2016ಡ್, ಯಾಸ್ಮಿನ್ ನ್ ಢಾಕಾ ವಿಶ್ವವಿದ್ಯಾಲಯದ ಸಾಮೂಹಿಕ ಸಂವಹನ ಬುಕ್ಕೊ ಪತ್ರಿಕೋದ್ಯಮದ ಹಿರಿಯ ವಿದ್ಯಾರ್ಥಿ ಸಂಘದ ಉಪಾಧ್ಯಕ್ಷೆರಾದ್ ನೇಮಕ ಮಲ್ತೆರ್.<ref>{{cite news |title=DUMCJAA forms new committee |url=https://www.thedailystar.net/city/dumcjaa-forms-new-committee-1261981 |work=The Daily Star |date=31 July 2016 |access-date=18 November 2016}}</ref> ಜಟಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್‌ದ ಪ್ರಧಾನ ಕಾರ್ಯದರ್ಶಿಯಾದ್ ಜಟಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್‌ದ ಪ್ರಧಾನ ಕಾರ್ಯದರ್ಶಿಯಾದ್ ಆಯ್ಕೆ ಆಯೆರ್.<ref name="bdn31Dec2016">{{Cite news |url=https://bdnews24.com/bangladesh/national-press-club-gets-farida-yasmin-as-first-female-general-secretary-shafiqur-elected-president |title=National Press Club gets Farida Yasmin as first female general secretary; Shafiqur elected president |work=bdnews24.com |date=1 January 2017 |access-date=30 December 2018}}</ref> ಡಿಸೆಂಬರ್ 18, 2018 ದಾನಿ ಜಾಟಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್‌ದ ಪ್ರಧಾನ ಕಾರ್ಯದರ್ಶಿಯಾದ್ ಮರು ಆಯ್ಕೆ ಆಯೆರ್.<ref>{{Cite news |url=https://www.dhakatribune.com/media/2018/12/18/saiful-farida-panel-sweeps-national-press-club-polls |title=Saiful-Farida panel sweeps National Press Club polls |work=Dhaka Tribune |access-date=30 December 2018}}</ref> ಆರ್ womeneye24.com ಪತ್ರಿಕೆದ ಸಂಪಾದಕೆರ್ ಬುಕ್ಕೊ ಪ್ರಕಾಶಕೆರ್.<ref>{{Cite web |url=http://womeneye24.com/ |title=WomenEye24.com – Communication for equality |language=en-US |access-date=26 July 2019}}</ref> ಡಿಸೆಂಬರ್ 31, 2020ಡ್, ಯಾಸ್ಮಿನ್ ಜಾಟಿಯಾ ಪ್ರೆಸ್ ಕ್ಲಬ್ ದ ಅಧ್ಯಕ್ಷೆರಾದ್ ಆಯ್ಕೆ ಆಯೆರ್, ಅಧ್ಯಕ್ಷೆರಾದ್ ಆಯ್ಕೆ ಆಯಿನ ಸುರುತ ಪೊಣ್ಣು ಪನ್ಪಿನ ಪೆರ್ಮೆಗ್ ಭಾಗಿ ಆಯೆರ್.<ref name=":0">{{Cite news |title=Farida elected first Jatiya Press Club female president |url=http://unb.com.bd/category/Bangladesh/farida-elected-first-jatiya-press-club-female-president/62688 |access-date=31 December 2020 |work=UNB |date=31 December 2020 |language=en}}</ref> ಆರ್ 581 ಮತೊಲೆನ್ ಪಡೆಯೆರ್, ಆಂಡ ಅರೆನ ಪ್ರತಿಸ್ಪರ್ಧಿ '''ಕಮಲ್ ಉದ್ದೀನ್ ಸಬುಜ್''' 395 ಮತೊಲೆನ್ ಪಡೆಯೆರ್.<ref name=":0" /> ಬಾಂಗ್ಲಾದೇಶದ ಆರ್ಥಿಕ ಗುಪ್ತಚರ ಘಟಕ ಸೆಪ್ಟೆಂಬರ್ 2021ಡ್ ಅರೆನ ಲೆಕ್ಕೊಲೆನ್ ಬುಕ್ಕೊ ಪ್ರೆಸ್ ಕ್ಲಬ್, ಢಾಕಾ ಯೂನಿಯನ್ ಆಫ್ ಜರ್ನಲಿಸ್ಟ್ಸ್ ಬುಕ್ಕೊ ಬಾಂಗ್ಲಾದೇಶದ ಫೆಡರಲ್ ದ ಇತರ ಚುನಾಯಿತ ನಾಯಕೆರೆನ್ ಪತ್ರಕರ್ತೆರೆನ ಒಕ್ಕೂಟ ಖಾತೆಲೆನ ಬಗ್ಗೆ ತನಿಖೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{Cite news |date=13 September 2021 |title=BFIU opens probe into bank accounts of 11 senior journalists |url=https://www.dhakatribune.com/bangladesh/corruption/258234/bfiu-opens-probe-into-bank-accounts-of-11-senior |access-date=19 August 2024 |work=[[Dhaka Tribune]]}}</ref> ಪತ್ರಕರ್ತೆರೆನ ಸಮುದಾಯೊದ ಚುನಾಯಿತ ನಾಯಕೆರೆನ್ ತನಿಖೆ ಮಲ್ಪುನ ಸರ್ಕಾರೊನು ಟೀಕೆ ಮಲ್ತ್ ದ್, ಪತ್ರಕರ್ತೆರೆನ ಮಿತ್ತ್ ಏರ್ಲಾ ದೂರು ಇಜ್ಜಂದೆ ತನಿಖೆ ದಾಯೆ ಮಲ್ತೆರ್ ಪಂದ್ ಪ್ರಶ್ನೆ ಮಲ್ತೆರ್.<ref>{{Cite news |date=2021-09-19 |title=Defamatory, ill-motivated |url=https://www.thedailystar.net/news/bangladesh/news/unprecedented-defamatory-ill-motivated-2179006 |access-date=2024-08-19 |work=The Daily Star |language=en}}</ref><ref>{{Cite news |date=2021-09-19 |title=Probe into journalists' bank details a 'scare tactic' |url=https://www.tbsnews.net/bangladesh/probe-journalists-bank-details-scare-tactic-304510 |access-date=2024-08-19 |work=The Business Standard |language=en}}</ref> ಮೇ ತಿಂಗೊಲುಡ್ ಬಂಧಿತ ಆಯಿನ 'ಪ್ರೊಥೊಮ್ ಅಲೋ' ದ ಪತ್ರಕರ್ತೆ ರೋಜಿನಾ ಇಸ್ಲಾಂ ನ ಬಂಧನದ ಲೆಕ್ಕೊನು ಸರ್ಕಾರ ಪರಿಶೀಲನೆ ಮಲ್ಪುನಗ ಉಂದು ನಡತ್ಂಡ್..<ref>{{Cite news |date=29 September 2021 |title=CPJ: Stop probing bank accounts of journo Rozina, 11 others |url=https://www.dhakatribune.com/bangladesh/259957/cpj-stop-probing-bank-accounts-of-journo-rozina |access-date=19 August 2024 |work=[[Dhaka Tribune]]}}</ref> ಯಾಸ್ಮಿನ್ ಗೃಹ ಸಚಿವ ಅಸದುಜ್ಜಾಮಾನ್ ಖಾನ್ ಕಮಾಲ್ ನ್ ತೂದು ರೋಜಿನಾನ ಕಿರುಕುಳೊನು ಟೀಕೆ ಮಲ್ತೆರ್, ಜಾಮೀನು ಕೋರ್ದು "ನಮಕ್ ನ್ಯಾಯ ಬೋಡು, ಈ ರೀತಿಡ್ ಏರೆನ್ಲಾ (ರೋಜಿನಾನ್) ಕಿರುಕುಳ ಕೊರ್ಪಿನ ಹಕ್ಕ್ ಏರೆಗ್ಲಾ ಇಜ್ಜಿ" ಪಂಡ್ದ್ ಪನ್ಪೆರ್.<ref>{{Cite news |last=Haque |first=Nabban T |date=18 May 2021 |title=Press Club president meets home minister over Rozina Islam |url=https://www.dhakatribune.com/bangladesh/dhaka/247036/press-club-president-meets-home-minister-over |access-date=19 August 2024 |work=[[Dhaka Tribune]]}}</ref> ಯಾಸ್ಮಿನ್ 31 ಡಿಸೆಂಬರ್ 2022 ಗ್ 567 ಮತೊಟು ಮರು ಆಯ್ಕೆ ಆಯೆರ್ ಬುಕ್ಕೊ ಕಮಲ್ ಉದ್ದೀನ್ ಸಬುಜ್ 401 ಮತೊಲೆನ್ ಪಡೆಯೆರ್.<ref>{{Cite news |date=2022-12-31 |title=Farida elected Jatiya Press Club president, Shyamal gen secy |url=https://www.thedailystar.net/news/bangladesh/news/farida-elected-jatiya-press-club-president-shyamal-gen-secy-3209591 |access-date=2024-08-19 |work=The Daily Star |language=en}}</ref> ಯಾಸ್ಮಿನ್ ನ್ ಅವಾಮಿ ಲೀಗ್ ಫೆಬ್ರವರಿ ೨೦೨೪ಡ್ ನರಸಿಂಗ್ಡಿಗ್ ಮಹಿಳಾ ಮೀಸಲು ಸ್ಥಾನೊ ಆದ್ ನೇಮಕ ಮಲ್ತ್ಂಡ್..<ref>{{Cite news |date=2024-02-14 |title=AL announces 48 candidates for reserved women's seats |url=https://en.prothomalo.com/bangladesh/politics/9cul4202bf |access-date=2024-03-01 |work=Prothom Alo |language=en}}</ref><ref>{{Cite news |date=2024-02-14 |title=JS reserved seats for women: AL finalises its 48 nominees |url=https://www.thedailystar.net/news/bangladesh/politics/news/js-reserved-seats-women-al-finalises-its-48-nominees-3543896 |access-date=2024-03-01 |work=The Daily Star |language=en}}</ref> == ಪ್ರಕಟಿತ ಪುಸ್ತಕೊಲು == * ಬಾಷಾ ಆಂದೋಲನ್ ಓ ನಾರಿ, 2005 * ಉಜ್ಜಲ್ ನರಿರ್ ಮುಖೋಮುಖಿ, 2005 * ತೆಹಶೇರ್ ಐನಯ್ ಬಂಗಬಂಧು, 2017 == ವೈಯಕ್ತಿಕೊ ಜೀವನ == ಯಾಸ್ಮಿನ್ 1990 ಟ್ ಪತ್ರಕರ್ತೆರಾಯಿನ '''ನಯೀಮ್ ನಿಜಾಮ್''' ಅರೆನ್ ಮದಿಮೆ ಆಯೆರ್.<ref name="qtyz" /><ref>{{Cite book |script-title=bn:নারী সাংবাদিকতায় অন্যন্য অবদান |last=সাপ্তাহিক |first=অন্যধারার কাগজ |date=January 2018 |location=Dhaka |pages=21 |language=bn}}</ref> == ಉಲ್ಲೇಕೊಲು == {{Reflist}} [[ವರ್ಗೊ:ವಿಕಿಪೀಡಿಯ ಏಷ್ಯನ್ ತಿಂಗೊಲು 2024]] d2tyjnfolu84kuhim6gb4rf4ellh3ey ಪ್ರಭಾಕರ ನೀರ್‌ಮಾರ್ಗ 0 20689 362737 361516 2026-07-13T01:55:49Z InternetArchiveBot 4316 Rescuing 0 sources and tagging 1 as dead.) #IABot (v2.0.9.5 362737 wikitext text/x-wiki {{More citations needed}} {{Infobox writer | embed = | honorific_prefix = | name = ಪ್ರಭಾಕರ ನೀರ್‌ಮಾರ್ಗ | honorific_suffix = | image = Prabhakara Neermarga.jpg | image_size = 175px | image_upright = | landscape = <!-- yes, if wide image, otherwise leave blank --> | alt = <!-- descriptive text for use by speech synthesis (text-to-speech) software --> | caption = | native_name = | native_name_lang = ತುಳು, ಕನ್ನಡ | pseudonym = | birth_name = <!-- only use if different from name --> | birth_date = <!-- {{Birth date and age|YYYY|MM|DD}} for living people supply only the year with {{Birth year and age|YYYY}} unless the exact date is already widely published, as per [[WP:DOB]]. For people who have died, use {{Birth date|YYYY|MM|DD}}. --> | birth_place = ನೀರ್‌ಮಾರ್ಗ, ದಕ್ಷಿಣ ಕನ್ನಡ | death_date = <!-- {{Death date and age|YYYY|MM|DD|YYYY|MM|DD}} (DEATH date then BIRTH date) --> | death_place = | resting_place = | occupation = ಬರವುಗಾರೆರ್ | language = | nationality = | education = ಬಿ. ಎ, ಎಂ.ಎ, ಎಂ.ಬಿ.ಎ , ಪಿಎಚ್.ಡಿ | alma_mater = <!-- use only per [[MOS:INFOEDU]] --> | period = | genre = <!-- or: | genres = --> | subject = <!-- or: | subjects = --> | movement = | notable_works = | spouse = <!-- or: | spouses = --> | partner = <!-- or: | partners = --> | children = | relatives = | awards = | signature = | signature_alt = | signature_size = | signature_type = | years_active = | module = | website = <!-- {{URL|example.org}} --> | portaldisp = <!-- "on", "yes", "true", etc.; or omit --> }} '''ಡಾ. ಪ್ರಭಾಕರ ನೀರ್‌ಮಾರ್ಗ''' ಮೇರ್ ದಕ್ಷಿಣ ಕನ್ನಡ ಜಿಲ್ಲೆದ ಮಂಗಳೂರು ತಾಲೂಕು ನೀರ್‌ಮಾರ್ಗ ಪನ್ಪಿ ಊರುಡು ಪುಟ್ಟಿಯೆರ್. ಬರವು ಸರವುಡ್ದು ಬುಕ್ಕೊ ಮಂಗಳೂರು ವಿಶ್ವವಿದ್ಯಾನಿಲಯೊದು ಬೇಲೆ ಮಲ್ತ್‌ದ್ ನಿವೃತ್ತಿ ಆತೆರ್. ==ವೃತ್ತಿ== # ಲೇಖಕೆರ್ # ವಿ.ವಿ.ಯ ನಿವೃತ್ತ ಉಪ ಕುಲಸಚಿವರು ==ವಿದ್ಯಾಭ್ಯಾಸ== ಬಿ. ಎ ಪದವಿ , `ಉನ್ನತ ಶ್ರೇಣಿಡ್ ಬಂಗಾರ್ದ ಪದಕ’ ಶ್ರೀ ಮಹಾವೀರ ಕಾಲೇಜು, ಮೂಡಬಿದ್ರಿ ಎಂ.ಎ ಸಾಹಿತ್ಯ (ಮೈಸೂರು ವಿವಿ) ಎಂ.ಬಿ.ಎ (ಅಲಗಪ್ಪನ್ ವಿವಿ) ಪಿಎಚ್.ಡಿ ಪದವಿ (ಮಂಗಳೂರು ವಿವಿ) == ಮಲ್ತಿನ ಬೇಲೆಲು== ವಿಶ್ವವಿದ್ಯಾನಿಲಯೊಡು ಆಡಳಿತ ಸೇವೆ ಉಪ ಕುಲಸಚಿವೆರ್ ಉಪ ನಿರ್ದೇಶಕ, ಅಂಚೆತೆರಪಿನ ಶಿಕ್ಷಣ ನಿರ್ದೇಶನಾಲಯ ಮಂಗಳೂರು ವಿ.ವಿ.ಯ ಉಪ ಕುಲಸಚಿವ ,ಎಸ್ಟೇಟ್ ಅಧಿಕಾರಿಯಾದ್ಸ ಸೇವೆ ಮಲ್ತ್ದ್ ೨೦೧೯ರಲ್ಲಿ ಸೇವೆಡ್ದ್ ನಿವೃತ್ತಿ ಆತೆರ್ == ಪ್ರಸ್ತುತ ಜಬದಾರಿ== ಪ್ರಾಂಶುಪಾಲರು, ಮ್ಯಾಪ್ಸ್‌ ಸಂದ್ಯಾ ಕಾಲೇಜು, ಮಂಗಳೂರು == ಬರೆಯಿ ಬೂಕುಲು== # ದಾಯಿತ್ವ: ಸಾಮಾಜಿಕ ಕಾದಂಬರಿ(1997) 99ನೇ ಅಖಿಲ ಭಾರತ # ಶಿಶಿರ:ಪ್ರೇಮ ಕಾವ್ಯ ಕಾದಂಬರಿ(1998) # ಪ್ರತಿಶೋಧ: ಸಾಮಾಜಿಕಕಾದಂಬರಿ (1999) # ತಿಲ್ಲಾನ:ತುಳುನಾಡಿನ ಸಂಸ್ಕತಿಯ ಬಗೆಟ್ ಕಾದಂಬರಿ(2000) # ಧೀಂಗಣ:ಯಕ್ಷಗಾನ ವಿಷಯೊಡು ಕಾದಂಬರಿ (2001)ದಕ್ಷಿಣ ಕನ್ನಡ ಜಿಲ್ಲಾ ಸಾಹಿತ್ಯ ಸಮ್ಮೇಳನದಲ್ಲಿ `ಶ್ರೇಷ್ಠ ಕೃತಿ’ ಪನ್ಪಿ ಪುರ್ಟೆ ಪಡೆತ್ಂಡ್ # ಅಘ್ರ್ಯ:ಸಾಮಾಜಿಕ ಕಾದಂಬರಿ (2002) # ದಳವಾಯಿ ದುಗ್ಗಣ:ತುಳು ಐತಿಹಾಸಿಕ ಕಾದಂಬರಿ (2003) ಪಣಿಯಾಡಿ ಪ್ರಶಸ್ತಿ ಪಡೆತ್ಂಡ್ # ತಂಬಿಲ:ನಾಗಾರಾಧನೆ ಬಗೆಟ್ ಕನ್ನಡ ಕಾದಂಬರಿ(2004) # ಭೀಕರ ನ್ಯಾಯಕಟ್ಟೆ:ತುಳು ಐತಿಹಾಸಿಕ ನಾಟಕ (2005) # ಕಂಬುಲ:ಕಂಬಳ ಜನಪದ ಕ್ರೀಡೆ ಆಧಾರಿತ ಕನ್ನಡ ಕಾದಂಬರಿ(2006) # ಮಂಗಳೂರು ಕ್ರಾಂತಿ:ಐತಿಹಾಸಿಕ ಕಾದಂಬರಿ(2007)ಪ್ರತಿಷ್ಠಿತ ವಿಶುಕುಮಾರ್ ಪ್ರಶಸ್ತಿ ಬುಕ್ಕೊ # # ಕರಾವಳಿ ಸಾಂಸ್ಕ್ರತಿಕ ಪ್ರತಿಷ್ಠಾನ ಸಾಹಿತ್ಯ ಪ್ರಶಸ್ತಿ ಪಡೆತ್ಂಡ್ # ಮಾದಿರ:ತುಳು ಸಂಸ್ಕತಿದ ಬಗೆಟ್ ಬ ಕನ್ನಡ ಕಾದಂಬರಿ(2008) # ಮದಿಪು:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2009) # ಮಥನ:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2010) # ಜಾತ್ರೆ:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2011) # ಭಾರಣೆ:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2011) # ವೇಷ:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2012) # ದಿಬ್ಬಣ:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2013) # ಗುರಿಕಾರ:ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ(2013) # ತರಿಕಿಟ:ಯಕ್ಷಗಾನ ಆದಾರದ ಬಗೆಟ್ ಕನ್ನಡ ಕಾದಂಬರಿ(2014) # ಕಾರ್ಣಿಕ: ಭೂತರಾಧನೆ ಕೇಂದ್ರೀತ ಕನ್ನಡ ಕಾದಂಬರಿ(2016) # ಕಾಲಚಕ್ರ: ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ (2017) # ಧರ್ಮಚಾವಡಿ: ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ (2018) # ಊರಸಂತೆ ಸಾಮಾಜಿಕ ಕನ್ನಡ ಕಾದಂಬರಿ ೨೦೧೮ # ಕಾಣದ ಕಡಲಿಗೆ ಕಾದಂಬರಿ ೨೦೧೯ # ತುಳುನಾಡು ನಾಡು ನುಡಿ ಸಂಸ್ಕೃತಿ (ಐತಿಹಾಸಿಕ) # ಕಣ್ಮಣಿ ಸಾಮಾಜಿಕ ಕಾದಂಬರಿ -2021[೩] # ತುಳು ಬದುಕು ಸಾಮಾಜಿಕ ಕಾದಂಬರಿ – 2022 # ಓಲಗ ಸಾಮಾಜಿಕ ಕಾದಂಬರಿ 2022 # ಸಾಗರದಾಚೆ ಒಂದುಲೋಕ<ref>{{Cite web |url=https://www.bookbrahma.com/author/prabhakar-neeramarga |title=ಪ್ರಭಾಕರ್‌ ನೀರ್‌ಮಾರ್ಗ |accessdate=2025-10-19 |website=www.bookbrahma.com |language=en }}{{Dead link|date=July 2026 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> ==ಬರವುದ ಬಗೆಟ್ ವಿಮರ್ಶಾ ಕೃತಿಕ್ಕುಲು== # `ಸಂಸ್ಕ್ರತಿ ಜಾತ್ರೆ’ - ಡಾ. ಸಾತ್ವಿಕ್# ನೀರ್‍ಮಾರ್ಗರ ಕಾದಂಬರಿಗಳಲ್ಲಿ ಪ್ರಾದೇಶಿಕತೆ’ - ಶ್ರೀ ಪ್ರತಾಪ್‍ಚಂದ್ರ ಶೆಟ್ಟಿ ಹಳ್ನಾಡ್ # ನೆಲದ ದನಿ’ ಪ್ರಭಾಕರ್ ನೀರ್‍ಮಾರ್ಗರ ಬದುಕು ಬರಹ - ಶ್ರೀ ಪ್ರತಾಪ್‍ಚಂದ್ರ ಶೆಟ್ಟಿ ಹಳ್ನಾಡ್(ಸಂ.) # ಸಿರಿಮರಾಯಿ – ಡಾ. ಪ್ರಭಾಕರ ನೀರ್‌ಮಾರ್ಗರವರ ಸಮಗ್ರ ಸಾಹಿತ್ಯಯಾನ [[ಬೆನೆಟ್‌ ಅಮ್ಮನ್ನ]] (ಸಂ.) === ಪ್ರಶಸ್ಥಿ ಪುರಸ್ಕಾರೊಲು === # "ಮಂಗಳೂರು: ಡಾ. ಪ್ರಭಾಕರ ನೀರ್‌ಮಾರ್ಗ ಅವರಿಗೆ ದ.ಕ.ಜಿಲ್ಲಾ ರಾಜ್ಯೋತ್ಸವ ಪ್ರಶಸ್ತಿ". November 2023. == ಉಲ್ಲೇಕೊಲು == http://www.insc.in/singleinfo?tid=7959{{Dead link|date=June 2026 |bot=InternetArchiveBot |fix-attempted=yes }} {{Reflist}} kq5cbgsh6h2k6hw67ur8gk6sdf50dhi ಮೋಡ್ಯೂಲ್ ಪಾತೆರ:Params 829 24137 362732 351474 2026-07-13T00:18:19Z Uzume 2969 /* Copied discussion */ಪೊಸ ವಿಭಾಗ 362732 wikitext text/x-wiki == New function <code>self</code> == I have added a new function to the module, &#123;&#123;[[Module:params|#invoke:params]]|[[Module:params#self|self]]&#125;&#125;, however I am not sure whether the most idiomatic name for it is <code>self</code> or <code>title</code> (especially considering that <code>self</code> has a special meaning in Lua). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:36, 27 September 2023 (UTC) :@[[User:Grufo|Grufo]]: I would prefer a different naming. Based upon magic words like {{tlm|PAGENAME}} and friends, things along the lines of <code>PARENTNAME</code>, <code>TEMPLATENAME</code> (sadly we already have a {{tl|TEMPLATENAME}} with a slightly different meaning), <code>INVOKERNAME</code> or similar come to mind, along with the possibilites of things like <code>CHILDNAME</code>, <code>MODULENAME</code>, <code>INVOKEENAME</code> or similar; potentially with modifiers for other encodings ''a la'' {{tlm|PAGENAMEE}} and [[mw:Manual:PAGENAMEE encoding#Encodings compared|comparison of page title encodings]], etc. (e.g., by returning [[mw:Extension:Scribunto/Lua reference manual#Title objects|mw.title:partialUrl()]] or similar), not to mention other options in line with things like {{tlm|FULLPAGENAME}}, {{tlm|FULLPAGENAMEE}}, etc. That said, perhaps those names are not really the best either and it would be better to stick to naming closer to Scribunto naming along the lines of <code>parentPageTitle</code>/<code>modulePageTitle</code> and stick to modifiers provided by <code>mw.title</code> object and/or <code>mw.url</code> API like <code>partialUrl</code>, <code>queryEncode</code>, <code>pathEncode</code>, <code>wikiEncode</code>, <code>anchorEncode</code>. Incidentally, I have often considered developing a Scribunto replacement for base (or even all the extensions in the default and/or WMF MediWiki packaging) magic words and then potentially extending it from there. This begs the need for these types of things more generally but I digress. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:51, 6 March 2024 (UTC) :: @[[User:Uzume|Uzume]] Sorry for my very late reply. Your suggestions would be <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKERNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CHILDNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|MODULENAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKEENAME}}</syntaxhighlight>. These would break the convention used for function names in this module, and also would not be so immediate to understand (i.e. if template <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> ''invokes'' this module I would expect “INVOKENAME” and the other names you propose to return <code>Module:Params</code> instead of <code>foobar</code>). There is a convention used by many programming languages according to which the parameter zero is the name of the routine executing the code (e.g. in [[Bash]] <code>$<nowiki />1</code>, <code>$<nowiki />2</code>, <code>$<nowiki />3</code>, … are the parameters, whereas <code>$<nowiki />0</code> is the name of the script or the name of the subroutine, much like our <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>). However in these languages parameters can only be non-zero positive numbers, whereas in template syntax <code>0</code> can also be a parameter name (e.g. <syntaxhighlight lang="wikitext" inline>{{foobar|0=hello|1=world}}</syntaxhighlight>), so another solution needs to be found. There used to be an <code>arguments.callee</code> property in JavaScript with a similar meaning, but [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee today is deprecated], and if we named our function <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CALLEENAME}}</syntaxhighlight> I believe it would create confusion in redirected templates. The name “self” is what for me comes the closest to “parameter zero” in those languages that use the latter for the same purpose. And so “self” inside <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> is <code>foobar</code>. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 22 May 2024 (UTC) :::@[[User:Grufo|Grufo]]: To me <code>self</code> tends to lend its meaning from Lua in much the same way as as <code>this</code> does in C++, namely an [[object (computer science)|object]] reference (although in C++ these are always [[class-based programming|class-based]] and in Lua they do not have to be as they could be [[prototype-based programming|prototype-based]], etc.). It is true that in MW "title" has several meanings but its most common meaning is a textual name of a {{em|page}}, that said I would try to avoid it based on things like [[mw:Manual:Modeling pages|Manual:Modeling pages]]. That said page "title" and <code>PAGENAME</code> tend to be the name of a page without a namespace, as opposed to <syntaxhighlight lang=lua inline>frame:getTitle()</syntaxhighlight> and <code>FULLPAGENAME</code>, etc. You asked how people felt about the naming of the current <code>self</code> invocation target and though I am not a fan of "self", I do think it is better than anything with "title" in its name. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 10:16, 23 May 2024 (UTC) :::: It's true I asked, but my concern was not about how understandable the term is, but about the fact that “self” has a peculiar meaning in Lua. And although this still holds true, it is also true that this module is not meant to be called by other modules (i.e. it is not meant to be used in Lua), but it is meant to be called by templates, where “self” has no special meaning whatsoever (plus, template writers are required to know nothing at all about Lua, and maybe one day modules will be written in more languages other than Lua). And ''even if'' a template writer knows about Lua, <code>self</code> would still make sense (i.e. the “Lua-style ''self'' from the point of view of a template is the template itself”). If you mention words that are already in use, they would carry the reference they currently have (e.g. “title” would refer to the transcluding page, not the transcluded template), so we do need to invent new words that carry no references, since no magic word or template currently offers the same functionality. For me the only possible contender would be <code>callee</code> (but see what I wrote earlier about the case of redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:42, 23 May 2024 (UTC) :::::Be verbose to avoid any confusion, it costs you nothing. How about calling_template_name? [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 11:20, 23 May 2024 (UTC) :::::: But that would be very confusing! This function is meant to be used in transcluded templates (otherwise one uses<syntaxhighlight lang="wikitext" inline>{{FULLPAGENAME}}</syntaxhighlight>); and if template <syntaxhighlight lang="wikitext" inline>{{foo}}</syntaxhighlight> calls <syntaxhighlight lang="wikitext" inline>{{bar}}</syntaxhighlight>, and the latter contains <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>, we get <code>bar</code>, which is the ''called'' template, not the ''calling'' template (which instead would be <code>foo</code> – of course, technically the called template is also ''invoking'' a module, but users need to know nothing about Lua and modules for using <syntaxhighlight lang="wikitext" inline>{{#invoke:params}}</syntaxhighlight>). It is not a coincidence that in JavaScript the same functionality was called <code>arguments.'''callee'''</code> (and not <code>arguments.'''caller'''</code> – but again, “callee”/“called” create confusion in redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:08, 23 May 2024 (UTC) :::::::In your example, template {{tl|bar}} is calling {{mlx|params|self}}, so {{tl|bar}} is the calling template (of your function), and its name is calling_template_name. It could be this_template_name as well. The word 'self' is usually used for the very object (with methods and stuff), not only its name. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 13:39, 23 May 2024 (UTC) :::::::: <code>this_template_name</code> would also be possible. Let's see if others prefer it to <code>self</code>. Contra: although the funcion is meant to be used in templates, nothing forbids to use it in non-transcluded pages, wehere there is no such thing as “this template”; or imagine the page <code>Template:Foobar/doc</code> using <code>this_template_name</code> for referring to itself instead of the actual template it is documenting (i.e. <code>Template:Foobar</code> – that would also create confusion with {{tl|TEMPLATENAME}}). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 21:09, 23 May 2024 (UTC) :::::::::this_function_caller, I don't think it can be more precise; self, though, is a bit confusing when a page transcludes a template invoking a template invoking the function, or any such mumbo jumbo. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 22:50, 23 May 2024 (UTC) :::::::::I cannot say I like {{code|this_template_name}}. Without doing strange manipulations like {{code|frame:newChild}}, etc. the parent frame should always be the frame that calls {{code|#invoke}}. Even when {{code|frame:callParserFunction('#invoke', ...)}} is called this is normally true as it will either refer to the calling module or if specifically called off the parent frame, the invoker's invoker frame (i.e., a grandparent but the actual invoker frame is hidden then). This is why from the Lua standpoint something like {{code|parent_fullpagename}} probably makes the most sense, however, as you said this is designed to be understood from the template or parent's point of view (the users of which should not need to understand Lua, etc.) and as such there are {{em|way}} too many confusing page names to begin with. To that end, I still like {{code|invoker_fullpagename}}. {{code|full}} should probably be included as {{code|FULLPAGENAME}} includes a prefixed {{code|NAMESPACE}} as this function also returns. If you really like the {{code|caller}} nomenclature then how about {{code|module_caller_fullpagename}} and if you really like the {{code|this}}, how about {{code|this_module_caller_fullpagename}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:06, 11 July 2025 (UTC) :::::::::FYI: {{ml|TEMPLATENAME|main}} now does this same thing too but I am not a fan of its naming either. I personally believe names like {{code|template_name}} or {{code|module_name}} should be considered in situations where they are made to be used with {{code|msg:}} or {{code|#invoke:}}, i.e, the namespace is not prefixed for template or modules but it is otherwise, including for the empty main namespace (for example when you want to transclude a main space page and need syntax like <code><nowiki>{{:mainspacepage}}</nowiki></code> or <code><nowiki>{{msg::mainspacepage}}</nowiki></code> but you don't need such for {{code|{{ns:10}}}} and in a similar fashion you don't need {{code|{{ns:828}}}} for {{code|#invoke:}}. This is exactly what things like {{tlx|TEMPLATENAME}} do because they are designed for constructions like <code><nowiki>{{{{TEMPLATENAME}}|...}}</nowiki></code> (in this case typically from a {{code|/doc}} subpage but one wants it to also render properly from the main template and/or its {{code|/sandbox}} subpage, etc., i.e., everywhere {{code|/doc}} is transcluded from). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:06, 11 July 2025 (UTC) == Wrapper template with pass-thru params == I'm a template writer and have newly discovered this Module, and am still getting on board with it, but have not used it yet. I think it probably will handle some use cases I have, but I'm not quite sure. One case that is typical for me, is a wrapper template with "pass-thru params", that is, the case of a wrapper template A, that calls template B passing thru all or almost all of A's params to B without alteration, and one or two more params with hard-coded values. For a concrete example, consider template {{tl|sfnlink}}. I want to create new wrapper template {{tl|sfnlinknb}}, that will have the identical params that sfnlink has, less param {{para|nb}}; the job of the wrapper, is to pass through all of its params to {{tl|sfnlink}}, and add {{para|nb|yes}} as well. The "pass-thru" part of this seems like the kind of thing I ought to be able to do with Module:Params, but I'm not quite sure. Maybe using <code>for_each</code>? Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:09, 3 December 2023 (UTC) :It looks like you have a working implementation using double transclusion and <code>for_each</code> in {{tl|sfnlinknb}} already, but if it's useful as an alternative approach, I just used <code>concat_and_call</code> to do the same thing in {{tl|autnum plain}}: [[Special:Diff/1188117126]]. [[User:DefaultFree|DefaultFree]] ([[User talk:DefaultFree|talk]]) 13:26, 3 December 2023 (UTC) :: [[User:DefaultFree|DefaultFree]], thank you '''so''' much for this. Your solution is infinitely better, and I've rewritten my wrapper using your idea. I had made multiple attempts—you can see the numerous failures at the history of [[User:Mathglot/sandbox/Templates/params_for_each]] and at [[Template:Sfnlinknb]]. At one point, I thought I had it because it worked perfectly at [[Special:ExpandTemplates]], but then I found it didn't work anywhere else—it spit out the correct code (as if it were nowiki'ed), but didn't invoke it, except at ExpandTemplates, for some reason. Then I went off on a tangent, trying to add {{tl|Eval}} in front of the whole thing to get it to execute, and as you saw, I got tangled up in double transclusion, and, oh, what a mess! Yours is so much better, and would make a great addition to the documentation of this Module, either as an example, or as a "Pro tip" note. (You might be interested to see what I did with the (on-page) /doc, the {{no redirect|Template:Sfnlinknb/sandbox|/sandbox}}, and the [[Template:Sfnlinknb/testcases|/testcases]] pages for {{tl|Sfnlinknb}}.) Thanks again, and I owe you one! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:29, 3 December 2023 (UTC) == 15th January 2024: New changes == The [[Module:Params/ChangeLog]] subpage now keeps the record of the most important changes in the module's code. Furthermore four new modifiers – <code>[[Module:Params#mapping_values_by_calling|mapping_values_by_calling]]</code>, <code>[[Module:Params#mapping_values_by_invoking|mapping_values_by_invoking]]</code>, <code>[[Module:Params#mapping_values_blindly_by_calling|mapping_values_blindly_by_calling]]</code> and <code>[[Module:Params#mapping_values_blindly_by_invoking|mapping_values_blindly_by_invoking]]</code> – were recently added to the module. These allow to pass each argument one by one to a custom template or a custom module in order to be preprocessed before further actions. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:07, 15 January 2024 (UTC) == growth and sandboxes == Hi {{ping|Grufo}} - following on from your request over at [[WP:PERM]]. Got a few questions: #Do you know what has recently caused the large growth in calls to this module? Is such a large use necessary? #This module doesn't appear to have a /sandbox; now that it is so heavily used where are changes being validated prior to deployment? Thanks, — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 13:34, 22 April 2024 (UTC) :{{u|xaosflux}}, the drastic usage increase looks to be due to [[Special:Diff/1214727698]]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:42, 22 April 2024 (UTC) ::Numbers should start falling, I've undone the above. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:50, 22 April 2024 (UTC) :::FYI to {{ping|Uzume}} — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:19, 22 April 2024 (UTC) ::::@[[User:Xaosflux|Xaosflux]]: Thanks for the heads-up. I just fixed a minor documentation bug. Using something like this module insulated it from potential moves (or someone copying it for as a template, etc.) but there are obviously other ways to fix that issue and I certainly did not mean for it to have such ramifications (I would not want to prevent the author from development; the sandbox still allows such if somewhat more cumbersome). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 14:31, 22 April 2024 (UTC) : Hi [[User:Xaosflux|Xaosflux]]. I have no idea. I tried to find out, but I believe that whoever is responsible for the growth did not follow the suggestion of adding {{Tl|Lua}} to the documentation of the templates that start using this module. So finding out where all the calls come from is hard (btw, someone has to improve the “What links here” special page and allow to list direct transclusions only…). I had planned some important improvements for this module, but I have been very busy in the last months. And as soon as I had a bit of time for the module I found out that I can no longer edit it. Concerning the sandbox: it's not hard to create one, is it? So far every time I posted an update I tested it locally on my machine, but I agree that it would be good to have a sandbox here too. '''EDIT.''' [[User:Primefac|Primefac]] gave the answer while I was writing mine (@[[User:Primefac|Primefac]]: Thank you). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 22 April 2024 (UTC) ::Always happy to help. For the record, I used an insource search to find where it was being invoked, specifically <code>insource:/invoke:params/</code>, as seen [https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&search=insource%3A%2Finvoke%3Aparams%2F here]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 14:19, 22 April 2024 (UTC) ::I've lowered the protection level on this, you should be able to edit again. Suggest you build up a sandbox and incorporate it to the testcases. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:21, 22 April 2024 (UTC) ::: Thank you both @[[User:Primefac|Primefac]] and @[[User:Xaosflux|Xaosflux]]! The next changes in the code will pass through a sandbox. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 14:30, 22 April 2024 (UTC) == Ready for general use == Improvements are always possible, but I believe [[Special:Diff/1224926156/1225161147|time has come]] to mark this module as [[:Category:Modules for general use|ready for general use]]. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:52, 22 May 2024 (UTC) == Inverting parameters == At {{tlf|[[WP:RSPUSES]]}}, I needed not <code>|1=key|2=value</code> but <code>|1=value|2=key</code>. I achieved this with <code><nowiki>{{#invoke:params|sequential|mapping_by_calling|duses|values_and_names|setting|i|<br>|list_values}}</nowiki></code> when <code>call_for_each</code> didn't work. Are there plans to add a shortcut like <code>call_for_each_value_and_key</code>? [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 21:56, 4 July 2024 (UTC) : You followed exactly the right way. There are no plans to create a <code>call_for_each_value_and_key</code> function, because that will mean that we will have to create also an <code>invoke_for_each_value_and_key</code> function, a <code>magic_for_each_value_and_key</code> function, a <code>call_for_each_key</code> function, and so on. This module is already quite rich in functions; if new functions will be added in the future it will probably be to add new functionalities, not just syntax sugar. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:56, 6 July 2024 (UTC) == Code link on mobile == {{re|Grufo}} Are you aware that the mobile view looks like this? <pre> ---------------------------------------- | Function | | |----------------------------------| | | | count | | | |----------------------------------| | | ( | | code | | ) | | Num. of arguments 0 | </pre> instead of the proper desktop view like this? <pre> |-----| Function |count| (code) |-----| -------------------------------- | Num. of 0 | | arguments | </pre> Ideally the entire header should be on the same line like on desktop. But the parentheses in the code link are currently a monstrosity on mobile. [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 06:03, 8 July 2024 (UTC) : @[[User:174.92.25.207|174.92.25.207]]: Thank you. I think the quirk is too infobox-specific to be integrated in the {{[[Module:Params/doc/link to the code|./doc/link to the code]]}} template. However [[Special:Diff/1233239047/1233369914|this]] should fix it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:45, 8 July 2024 (UTC) == Minor limitation currently affecting some functions == There is currently a design limitation in the [[:mw:Extension:Scribunto/Lua reference manual#frame:newChild|child frame]] object that affects <code>[[Module:Params#invoke_for_each|invoke_for_each]]</code>, <code>[[Module:Params#invoke_for_each_value|invoke_for_each_value]]</code>, <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> and <code>[[Module:Params#renaming_by_invoking|renaming_by_invoking]]</code>. The limitation affects these functions only when used on a large number of parameters (> 99). For more information see: * {{Section link|Wikipedia talk:Lua/Archive 12|Editing the args metatable of a child frame}} * [[:mw:Topic:Y61qv62t0k0w2b7f|Topic on Extension talk:Scribunto/Flow § Design problem in the frame object]] --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 20:03, 14 April 2025 (UTC) :@[[User:Grufo|Grufo]]: It seems like the best solution would be to avoid your current {{code|:newChild}} hacks and instead do actual {{code|#invoke:}} parser function calls via {{code|:callParserFunction}}. That also solves a number of problems with the current solution (besides the 99 frames limit), e.g., the current "invocation" method does not always work correctly for modules that attempt to detect such things (e.g., ones that test their inbound {{code|...}} to see how the module is being loaded, either as a {{code|#invoke:}} "main" or as a {{code|require}} sub-library module, {{code|mw.loadData}}, etc.). It also allows you to jettison some error code as true {{code|#invoke:}} already throws errors when the function cannot be found, etc. Don't try and reinvent the wheel (I ran into a similar situation with [[Special:Diff/954154594/prev|954154594]]). It also allows you the ability to potentially consolidate your code as your template {{code|call}} interfaces could be moved from {{code|:expandTemplate}} to {{code|:callParserFunction}} with {{code|msg:}} and both {{code|#invoke:}} and {{code|msg:}} could be implemented with your {{code|magic}} functions which already use {{code|:callParserFunction}}. The {{code|invoke}} function of <code>[[Module:Lua call]]</code> is a good example. Most uses of {{code|:newChild}} are typically poorly designed. One probably legitimate use would be to create an artificial parent frame for calling {{code|:callParserFunction}} off of (for modules that look at their parent frame, etc.). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:05, 9 July 2025 (UTC) :: Thank you, [[User:Uzume|Uzume]]. You make a strong point when you talk about modules that detect whether they have been called via <code>require()</code> or <code>#invoke</code>. I did not even know that was possible (how does one do that?). I have been thinking for a while about replacing <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code> in the functions listed above. I have not done it so far because I was hoping to trigger a rethinking upstream on how <code>:newChild()</code> is currently designed. However no discussions have emerged so far as far as I know (and so maybe now it is the time to get rid of <code>:newChild()</code>). At the moment, when facing the bug described here, it is already possible to use <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code> (which is why this did not seem to be an urgent fix). For instance, if we wanted to use {{mfl|string|replace}} to replace spaces with hyphens in values (and forgetting for a moment that we already have <code>{{mfl|params|mapping_by_replacing|...}}</code>), we could already do ::: <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_invoking]]&#124;[[Module:String|string]]&#124;[[Module:String#replace|replace]]&#124;4&#124;%s+&#124;-&#124;&#124;false&#124;...</code> :: or, equivalently, ::: <code>...&#124;[[Module:Params#mapping_by_magic|mapping_by_magic]]&#124;#invoke&#124;values_only_as&#124;3&#124;let&#124;1&#124;[[Module:String|string]]&#124;let&#124;2&#124;[[Module:String#replace|replace]]&#124;4&#124;%s+&#124;-&#124;&#124;false&#124;...</code> :: Interestingly, while <code>#invoke</code> is recognized as a parser function, the same seem not to apply to <code>msg</code>, and so it seems not possible to use the latter in combination with <code>:callParserFunction()</code>. In any case, <code>:expandTemplate()</code> seems to work just fine. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:19, 10 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: I am not sure why {{code|msg}} would not work as a parser function. I wonder if that is also true for {{code|msgnw}} (which is sort of similar to Scribunto {{code|mw.title:getContent()}} because it does {{em|not}} process page source through the main wikitext parser). I wonder if there is an issue with the way you are building your argument list or calling the parser function that is limiting things. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::Anyway, I am not sure about all the ways for Lua modules to detect how they are called but one of the primary ones would be to check {{code|...}} during the execution of the module initialization block (which executes during {{code|#invoke}} before the function call to the its first argument and why it is possible to catch {{em|any}} argument as the function name using a metatable with {{code|__index}} like in <code>[[Module:Ustring]]</code>; oddly enough that also means one can process the frame args {{em|before}} the function name is provided to the module but of course nothing can be returned until later). {{code|require()}} passes in the module's name while Scribunto {{code|#invoke}} does not (imitating command line {{code|lua}} but the frame args are {{em|not}} put into {{code|...}} or global {{code|arg}} so they are always empty/{{code|nil}}; probably because frame args have non-sequential parameter keys). Checking {{code|...}} can be a good way to have the module return a different {{em|package}} table (often denoted as just {{code|p}}) based upon whether it is loaded via {{code|#invoke}} or not. In fact, that style of coding allows one to do away with the awkward leading underscore API functions and even allows the module to {{code|require}} itself during {{code|#invoke}} thereby using its own API while also providing {{em|frame}} wrapper function(s) for {{code|#invoke}} calls from wikitext. The name of the module used during {{code|#invoke}} is of course provided via {{code|frame:getTitle()}} which can be accessed from anywhere, including the module initialization block, via {{code|mw.getCurrentFrame()}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::I created an example module for demonstrating how a module can detect how it is loaded at <code>[[Module:Sandbox/Grufo]]</code>. Feel free to do with it as you see fit. Notice how your {{code|require()}} plus {{code|frame:newChild()}} implementation likely would not work with that construction but a {{code|frame:callParserFunction('#invoke', ...)}} construction would. You should consider which frame to call that off-of though. Frequently it makes more sense to call that off of the parent so that the new invocation has the same parent as where you call it from (i.e., they are effectively "sibling" invocations) as arguments to your module might not be particularly interesting to the module you are invoking (if they are, you should probably pass them to the module directly via its own arguments) but arguments to the parent template would otherwise be lost (due to frame depth; a module can only access its frame and one parent—no grandparents, etc.). I am not sure if it matters which parent frame is available for other parser functions/magic words but I encourage you to consider using {{code|frame:callParserFunction()}} from the parent frame. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::FYI: another little known fact is that Scribunto has translations of {{code|#invoke}} so such can actually be accessed via alias keywords on for example a Korean or Russian Mediawiki, etc.; that makes it pain to search for all such invocations of a module but luckily few people know and use aliases. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::: Hi [[User:Uzume|Uzume]]. Thank you for the sandbox module. I think I understand now. As for <code>msg</code>, you can check yourself: ::::* <syntaxhighlight lang="wikitext" inline>{{if|eq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{if|eq|a|a|x|y}} ::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}} ::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}} ::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}} :::: You can also experiment with a new module and <code>:callParserFunction()</code> to see if there is a problem in [[Module:Params]]. But there are no reasons to replace <code>:expandTemplate()</code>. As for replacing <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code>, we need to see if in these language in which they use a local translation of <code>#invoke</code> the English <code>#invoke</code> still works (I think it should). Otherwise this module will become a nightmare to maintain. If the English <code>#invoke</code> does not work we should leave the module as it is and simply warn that in case of > 99 parameters or in case of modules that check how they have been invoked, people should use the local version of <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code>. I wonder what the performance difference is between using <code>:callParserFunction()</code> + <code>#invoke</code> and <code>:newChild()</code>. I will run some tests. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 15:34, 11 July 2025 (UTC) :::::@[[User:Grufo|Grufo]]: I think {{code|msg}} not being recognized as a parser function is likely a bug. The question is where the bug is: your module, the Scribunto extension, MediaWiki proper or some other weird place (i.e., unforeseen interaction somewhere). As shown below, the first argument can cause this error in some cases: :::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}</syntaxhighlight> :::::*: ↳ {{#invoke:params|new|concat_and_magic|canonicalurl|:ja}} :::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}</syntaxhighlight> :::::*: ↳ {{#invoke:params|new|concat_and_magic|canonicalurl|::ja}} :::::This definitely needs more investigation. I might have to look into that. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC) :::::Yes, Scribunto ensures {{code|#invoke}} always works even when there are localized alias names. This is in a fashion similar to MediaWiki base namespace names, e.g., Chinese Wikipedia might have another name for <code>{{ns:10}}</code> but that name always works everywhere (even here we have a different base name for the {{code|Project}} namespace but {{code|Project}} still works; i.e. <syntaxhighlight lang="wikitext" inline>{{ns:Project}}</syntaxhighlight> yields <code>{{ns:Project}}</code> and <syntaxhighlight lang="wikitext" inline>{{ns:Image}}</syntaxhighlight> yields <code>{{ns:Image}}</code>, etc.) they just act like a redirect alias to the localized name. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC) :::::FYI: Another little known fact is that {{em|all}} Scribunto module pages are in content language English (I am not sure that is really the right choice but I am not planning to fight it anytime soon) even on Mediawiki instances where English is really used nowhere else. As an example, try going to [[zh:Special:EditPage/Module:Var#mw-scribunto-console]] and type into the debug console: <syntaxhighlight lang="lua" inline>mw.log(mw.title.getCurrentTitle().pageLang.code)</syntaxhighlight>. You will get: {{code|en}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC) :::::: {{Re|Uzume}} Now I don't have the time to create a test module and check <code>:callParserFunction()</code> with <code>msg</code>. However writing <code>::ja</code> as argument seems to make the <code>canonicalurl</code> parser function invisible even when called directly (see third example): ::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl:ja}}</syntaxhighlight>; the latter yields ::::::#: ↳ {{canonicalurl:ja}} ::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl::ja}}</syntaxhighlight>; the latter yields ::::::#: ↳ {{canonicalurl::ja}} ::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl:::ja}}</syntaxhighlight>; the latter yields ::::::#: ↳ [[:Template:Canonicalurl:::ja]] :::::: As for moving from <code>:newChild()</code> to <code>:callParserFunction()</code> + <code>#invoke</code>, as soon as I have a moment I will update [[Module:Params/sandbox]] and run a few tests. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:13, 11 July 2025 (UTC) :::::::@[[User:Grufo|Grufo]]: Yes, that is interesting how the parser decides that syntax could not be a parser function call (because the argument is not a legal pagename?) and then falls back to parsing it as a template invocation of that pagename. The error from {{code|frame:callParserFunction()}} is definitely coming from [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/LuaEngine.php#L807-L810 the Scribunto PHP code] but the point you bring up may in fact be related (see below). As memory serves, when the parser is parsing normal wikitext, it handles parser function calls by parsing out the name and the chunk of wikitext to the end of the call (i.e., <code>{{))}}</code>) only separating them out by <code>{{!}}</code> and then calling the parser function code itself giving it a chance to "claim" the provided wikitext arguments (which are {{em|not}} yet fully parsed) and the parser function then decides how to parse such (some use the frame parser but many do not, e.g., {{code|#switch}} depends on the order/positioning of its arguments so it cannot use the frame parser and this is also why Scribunto {{code|#invoke}} can never perfectly emulate it) but I believe the parser function can also return to the parser stating it does not claim the provided wikitext arguments and in such a case the parser must march on assuming that it was not in fact a call to that parser function. I believe that is what is happening in your example above. Maybe something similar is happening in the {{code|frame:callParserFunction()}} path. It would kind of make sense there would be no way to actually call the parser function with entirely pre-parsed arguments so that path perhaps reconstructs the pseudo-unparsed wikitext arguments from the provided arguments and passes it to the parser function just as it would during normal wikitext processing. Then if the parser function rejects it, the parser assumes it was not a parser function call and eventually Scribunto yields the error: {{error|function "{{var|function}}" was not found.}} since there is probably no way to differentiate this from someone trying to call a nonexistent parser function, meaning the "not found" in the error is deceptive and should probably say something more like {{error|failed to execute function "{{var|function}}".}} Maybe this is an issue with the way the pseudo-unparsed wikitext arguments are reconstructed that causes {{code|msg}}, {{code|msgnw}} and {{code|raw}} to always reject the call. There may also be something special about {{code|msg}} and friends as in the history of wikitext parsing it was the {{em|first}}—even before normal template syntax existed and template syntax was implemented as a simplification. I wonder if {{strong|parsoid}} has the same issue. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 20:17, 11 July 2025 (UTC) :::::::: @[[User:Uzume|Uzume]]: I agree that the error is deceptive. Let me know if you find out more. In the meanwhile I have updated [[Module:Params/sandbox]] with a new version that replaces <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code>. It will still require extensive testing. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 05:17, 12 July 2025 (UTC) :::::::::@[[User:Grufo|Grufo]]: Okay, yes, I have determined parser functions themselves {{em|can}} and apparently sometimes {{em|do}} return the PHP value <syntaxhighlight lang=php inline>[ 'found' => false ]</syntaxhighlight> which will ultimately lead to that error, however, I think the issue with {{code|msg}}, {{code|msgnw}} and {{code|raw}} is different. I notice they do not show up on [[Special:Version#mw-version-parser-function-hooks]]. They are clearly magic words that take parameters but it looks like they might be handled special by the parser and technically are not parser functions or something which would explain why they cannot be reached by [https://github.com/wikimedia/mediawiki/blob/a5b5777ae4ec274a4ee347c5716d9a4b8180b1fb/includes/parser/Parser.php#L3460 <syntaxhighlight lang=php inline>MediaWiki\Parser\Parser()->callParserFunction()</syntaxhighlight>] (and it {{em|does}} rebuild the arguments for parser function calls in a sort of pseudo-unparsed fashion and the first argument has some special handling) which is used by [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/LuaEngine.php#L775 <syntaxhighlight lang=php inline>MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaEngine()->callParserFunction()</syntaxhighlight>] and ultimately via its Lua library interface. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC) ::::::::::@[[User:Grufo|Grufo]]: Okay, I read through the main parser again and in {{code|braceSubstitution()}} it clearly shows that {{code|msg}}, {{code|msgnw}} and {{code|raw}} are {{strong|NOT}} parser functions. It looks for and handles these in this order: ::::::::::#{{code|subst}} and {{code|safesubst}} prefixes ::::::::::#variables (which are sort of like argument-less parser functions) ::::::::::#{{code|msg}}, {{code|msgnw}} and {{code|raw}} prefixes ::::::::::#parser functions by actually calling the same interface Scribunto calls: {{code|callParserFunction}} ::::::::::#page transclusions, i.e, template syntax ::::::::::#special transclusions from "special pages" ::::::::::Then that function finishes up with some other processing like loop checking and HTML DOM updates, etc. ::::::::::The {{code|msg}}, {{code|msgnw}} and {{code|raw}} prefixes "work" because they are mostly just deleted and do nothing but the code continues on and eventually finds the template transclusion so it appears to do that. {{code|msgnw}} and {{code|raw}} do set some flags but the same flags can sometimes also be set by some of the parser functions which can be seen in the handling at the return of the parser function call. This means some weird syntax is allowed, e.g., <syntaxhighlight lang=wikitext inline>{{msg:canonicalurl:ja}}</syntaxhighlight> and <syntaxhighlight lang=wikitext inline>{{canonicalurl:ja}}</syntaxhighlight> both yield {{msg:canonicalurl:ja}} but one can also do <syntaxhighlight lang=wikitext inline>{{msgnw:canonicalurl:ja}}</syntaxhighlight> which yields {{msgnw:canonicalurl:ja}} (notice no link; this is because "nw" means nowiki but not as in the strip-marker generating tag but as in HTML entity escaping). It also means that this type of functionality is {{em|not}} directly available from Scribunto Lua (at least not without {{code|frame:preprocess()}}). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:03, 12 July 2025 (UTC) :::::::::Here are some more examples of core parser functions (I do not plan to go searching through every extension) that themselves return the deceptive "not found": :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|int|help}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|int|help}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|int|}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|int|}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#interwikilink|d}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|#interwikilink|d}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#interwikilink|x}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|#interwikilink|x}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|project}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|project}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|xyzzy}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|xyzzy}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|829xyzzy}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|829xyzzy}} :::::::::Oddly this one never returns the error so long as it is passed a value that starts with an integer value other than {{code|0}} (and it also takes exactly {{code|0}} too) even when such an integer value corresponds to no such namespace, e.g., <syntaxhighlight lang="wikitext" inline>{{ns:-500xyzzy}}</syntaxhighlight> parses as a valid parser function call. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC) :::::::::One thing about parser functions "failing" that bothers me is that there does not seem to be anything that specifies to the parser this type of dependency. One of the key tenants of parsoid is to be able to (re)parse parts of a page potentially out of order doing the right thing based upon a dependency chain (sort of like a software build tool like [[make (software)|make]]). A key example is the new {{code|#interwikilink}} which fails when it is provided an invalid interwiki prefix but that is dependent on MediaWiki configuration. This means that I could place some wikitext somewhere that calls {{code|#interwikilink}} and fails but at some future point it might suddenly succeed. Suppose I lobby for some new interwiki prefix at [[m:Talk:Interwiki map]] and it succeeds and soon afterwards is deployed. Does this mean all MediaWiki wikis at WMF (and whatever else uses those maps) needs to reparse {{em|all}} pages everywhere (Commons literally has millions) because they {{em|might}} contain wikitext that will now suddenly render differently (properly)? If this dependency was somehow stored then the parser would know which pages (and/or page parts) to reparse (and whatever depends on them in turn, etc.). But nowhere is it documented, let alone specified, when and how a parser function will choose to parse something (or lack thereof; i.e., fail and not parse something). So the main parser cannot know when such parser functions change their mind. Maybe I am overthinking things because there are clearly timestamp type of magic words that obviously change their minds on a regular basis and things are just kept "fresh" at a regular cadence. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC) :::::::::: <span class="anchor" id="speed-test-1"></span>@[[User:Uzume|Uzume]]: I think you should bring the part of this discussion that concerns parser functions to [[:mw:Extension talk:ParserFunctions]]. Going back to the original point, here is the bad news about my latest experiments. If I write the following wikitext (which uses <code>:newChild()</code>) 12 times in a page and display the preview, I get an average “Lua time usage” of &lt; 0.1 seconds: :::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params|new| imposing|99|| filling_the_gaps| mapping_by_replacing||true|1|strict| mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false| for_each|[$#::$@]}}</syntaxhighlight> :::::::::: On the other hand, if I write the following wikitext (which uses <code>:callParserFunction()</code> + <code>#invoke</code>) 12 times in a page and display the preview, I get an average “Lua time usage” of 0.7 seconds: :::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params/sandbox|new| imposing|99|| filling_the_gaps| mapping_by_replacing||true|1|strict| mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false| for_each|[$#::$@]}}</syntaxhighlight> :::::::::: Therefore now I am no longer so sure we should drop <code>:newChild()</code>… --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:34, 12 July 2025 (UTC) :::::::::::@[[User:Grufo|Grufo]]: I do not think [[mw:Extension talk:ParserFunctions]] is appropriate at all. That would be for discussion just about that extension including the parser functions from that extension, e.g., {{code|#expr}}, {{code|#if}}, {{code|#ifeq}}, {{code|#titleparts}}, etc. but not about parser functions in general nor about core parser functions. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC) :::::::::::As for your performance data, that is very interesting but remember, though {{#invoke}} does have nontrivial overhead (and there are some Phabricator issue tickets about such things) it also means your client code can run loops more than 99 times so long as they do not run out of resources {{em|and}} that they will run properly even with modules that detect how they are loaded and provide a different package interface when loaded via {{code|require}} than with {{code|#invoke}} (it is also trivial to detect {{code|mw.loadData}} but that is sort of a moot point from your perspective as it can only return static data that cannot be executed). So yes, your {{code|newChild}} hack is somewhat faster but it is also buggy and your clients will half to take that into account. I am assuming ([[Module:Params]] is long with lots of indirection; I did not read through all of it) you are calling both {{code|newChild}} and {{code|callParserFunction}} off the parent frame to keep that in tact for the target module. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC) :::::::::::[[Module:Params]] claims it is not designed to be used from other modules via {{code|require}}. To that end it could detect how it is loaded and provided a different interface when loaded via {{code|require}} keeping people from accessing it in such a manner (or fixing it so it does provide useful functionality under such conditions). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC) {{outdent|:::::::::::}} @[[User:Uzume|Uzume]]: Uh right. With this module being invoked via wikitext, the information that the second module (e.g. [[Module:String]] in my examples) has not been called via <code>require()</code> should be propagated and inherited, right (even if we actually call that via <code>require()</code>)? As for <code>:newChild()</code>, I was wondering if a solution like <code>frameTools.makePseudoFrame()</code> found [https://dev.fandom.com/wiki/Global_Lua_Modules/FrameTools here] could solve everything. The 99 parameter limit comes from a limitation in the number of child frames that can be created, however we don't really need so many child frames, since they are all identical except for one or two parameters. The ideal solution would be that they make the <code>frame.args</code> metatable editable upstream, so that we stick to one. Lacking that, I was wondering if we could use the “pseudo frame” object mentioned in that wiki. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:32, 13 July 2025 (UTC) :@[[User:Grufo|Grufo]]: You mean will the [[Fandom (website)|Fandom]] {{code|makePseudoFrame}} from [[CentralWikia:dev:Module:FrameTools|Module:FrameTools]] (with the documentation you mentioned at [[CentralWikia:dev:Global Lua Modules/FrameTools|Global Lua Modules/FrameTools]]) solve your problems? Yes...no and maybe. I am not exactly sure without testing but I think the concept is mostly sound. That said, it {{em|definitely}} introduces more caveats. :There is no guaranteed your target module will even use the {{code|frame}} argument it is provided in the call as it can always fetch the real frame from {{code|mw.getCurrentFrame()}} and you are almost guaranteed that it will use such during package initialization if it wants access to the frame at all, because there is no other method for access (at that point the {{code|frame}} argument is not available as it is before the target function has even been indexed much less called because it is the initialization block that returns the package table the target function is indexed from). One common idiom I have seen here is a package function that uses a construction like {{code|lang=lua|1=if frame == mw.getCurrentFrame() then}} allowing the package function to potentially work under {{code|#invoke}} {{em|or}} {{code|require}} (I do not consider this practice as good as the example module I gave you but it does something {{em|somewhat}} similar in attempting to handle both situtations). Currently, a search of all EN Wikipedia Scribunto module code for {{code|getCurrentFrame}} {{sl|all: contentmodel:Scribunto insource:/getCurrentFrame/|yields 620 hits}}. Of those, I found this programing idiom at:{{div col|content={{ulist |[[Module:Archive list alpha#L-329--L-337]] |[[Module:Archive list#L-313--L-321]] |[[Module:Armenian#L-10--L-18]] |[[Module:BaseConvert#L-89--L-93]] |[[Module:BellezzasoloUserPageModule#L-139--L-143]] |[[Module:British regnal year#L-12--L-20]] |[[Module:Csdcheck#L-24--L-36]] |[[Module:Fixme#L-71--L-79]] |[[Module:Japanese calendar#L-214--L-222]] |[[Module:PageLinks#L-274--L-282]] |[[Module:QuidAppearances#L-65--L-69]] |[[Module:Random#L-298--L-304]] |[[Module:Roman#L-98--L-106]] |[[Module:Sandbox/Ahecht/interwiki#L-80--L-88]] |[[Module:Sandbox/AlphaZeta/test4#L-25--L-29]] |[[Module:Sandbox/Frostly#L-237--L-245]] |[[Module:Sandbox/Hawkeye7#L-177--L-185]] |[[Module:Sandbox/Mlkj#L-313--L-321]] |[[Module:Sandbox/Retro#L-26]] |[[Module:Sandbox/Szqecs/Adjacent_stations#L-164--L-168]] |[[Module:Sandbox/Toohool#L-22--L-34]] |[[Module:Track gauge#L-11--L-19]] }}}} :These all use {{code|getCurrentFrame}} and soon compare it to something with {{code|1===}} (oh, and be glad I did not spam you with all the {{code|/sandbox}} copies too). All of these will {{em|already}} fail with your {{code|newChild}} hack (unless you call {{code|callParserFunction('#invoke', ...)}} off the {{code|newChild}} frame but that sort of defeats your purpose for using it to begin with) because in Lua comparing two tables always fails unless they are the same table reference (i.e., {{code|1===}} does not do a "deep compare" to compare the table contents so it is only true if they are in fact the exact same table not a copy). And there maybe other modules that do such as well but hold the {{code|getCurrentFrame}} value and compare it in some other fashion or compare it at some later time, etc. I only looked briefly at the 620 search hit results. I did not look directly at the module code from all 620 hits. Incidentally, I also looked for comparison via {{code|1=~=}} but I could not find a single such usage which I find a bit odd as I would probably prefer that myself but apparently that is not popular. I almost never depend on the provided frame argument as it is not really reliable and {{code|getCurrentFrame}} is (although I suppose someone {{em|could}} attempt to [[monkey patch]] the {{code|getCurrentFrame}} field of the {{code|mw}} package table/global). :Scribunto {{code|newChild}} actually calls into the PHP code to create a new [[mw:Manual:PPFrame.php|PPFrame]] object (notice its own PHP {{code|newChild}} method) that the MediaWiki parser and extensions, etc. can all use. Fandom {{code|makePseudoFrame}} does not appear to do this but just creates a fake one in Lua by copying fields from another Lua frame table. To that end, it is worse than {{code|newChild}} but from your perspective, I would say it is perhaps considerably better. Consider this: {{code|makePseudoFrame}} is probably no worse than {{code|newChild}} with regard to using it and {{code|require}} to fake a {{code|#invoke}}. Both have same caveat of not being the frame of an actual {{code|#invoke}}. However {{code|makePseudoFrame}} has the additional caveat of introducing potential issues for the target module if it uses the provided pseudo-frame to call back into MediaWiki (e.g., where do you think the parser will get arguments for parameter references like {{param|1}} in a {{code|preprocess}} call?). If you use {{code|newChild}} you are trapping those in the new PPFrame (which PHP does not let you change and this is why Lua does not let you change them either; this is also the source of the frame count limitation) so those references work (even if the target module {{code|could}} detect is is not actually being be called via {{code|#invoke}}). This is why I say {{code|makePseudoFrame}} introduces more potential caveats. On the other hand, it will likely be considerably faster as it does not call into PHP and it will not have the PHP frame count limitation (and you probably can write into its arguments although since it is a purely Lua table and its overhead is small you can probably just ensure it gets deleted and recreate it cheaply). My take on it is that if you are considering keeping your {{code|require}} based {{code|#invoke}} emulation, you would likely be better to switch from {{code|newChild}} to {{code|makePseudoFrame}}, however, I would encourage you to pursue a proper {{code|#invoke}} solution over the {{code|require}} based emulation. And at the very least you should rename and very clearly document that those functions in {{mlx|Params}} are {{code|#invoke}} emulations that have lower overhead but only work sometimes when the target module does not do much discrimination on how it is actually loaded (e.g., initialization block {{code|...}}), its provided frame arguments (e.g., comparing it to {{code|getCurrentFrame}}) or calling back into PHP in certain ways (e.g., {{code|preprocess}} with {{code|makePseudoFrame}}). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:12, 13 July 2025 (UTC) :: Thank you for your incredibly detailed answer, [[User:Uzume|Uzume]]. What I don't understand is this: how is possible that if I want to call a module via <code>require()</code> + <code>:newChild()</code> I hit the &lt; 100 parameters limitation, whereas <code>#invoke</code> is able to bypass it? How does it do it? Shouldn't it suffer from the same PHP limitation too? I was thinking that maybe the best solution at the moment is to leave everything as it is and write about it in the documentation. I think so because this is the solution that gives the maximum freedom of choice. Currently if one wants to favour performance can use, for instance <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_invoking]]&#124;...</code>, whereas if one wants to have the possibility of having 1000 parameters (at the cost of a slower solution) can use <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_magic]]&#124;#invoke&#124;...</code> --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 17:35, 13 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: I took a brief look at your module's usage of {{code|newChild}} as well as {{code|makePseudoFrame}} (which can be directly compared with Scribunto's own <code>[https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/lualib/mw.lua#L153-L456 newFrame]</code>). First, you should really consolidate your {{code|#invoke}} code whether it is an emulation or not (and while you're at it also encapsulate {{code|expandTemplate}} and {{code|callParserFunction}}; FYI: I do not like your usage of the word "magic" as it only supports parser functions not all types of magic words so you should really consider renaming those too). There is no reason to have five copies scattered around needing different maintenance. :::How about a single invoker that takes an emulation parameter and either does a real invoke or emulates one? Then the caller can choose, and if you really get daring, the parameter can be more than a boolean specifying the emulation type, i.e., to what lengths should the emulation employ. There are some things I am not too thrilled with about {{code|makePseudoFrame}} (and I think I found a minor bug in it too). If you are serious about trying to maintain a {{code|#invoke}} emulator, I have some ideas on how to build a better mousetrap. :::I am not sure if there is a good way to fake the environment for the module initialization block (e.g., {{code|...}}, etc.) as hacking that would probably have security implications and as such is likely locked down well but remember that it runs at a very different time to the execution of the package functions which get executed later either by Scribunto directly (i.e, via {{code|#invoke}}) or by Lua calls from module code, typically needing a {{code|require}} to get access to the package. If you look at {{code|newFrame}}, Scribunto's own frame object generation code, you might notice that they are generic tables without a metatable. Sure, the {{code|args}} field is another subtable and it is {{em|definitely}} metatabled but the main frame objects do not seem to be (of course someone might go and change things at some later date but at the moment that is true). To that end, it gave me an idea to help you with your emulation and potentiality alleviate your 99 frame limit whoas. Why not use real {{code|newChild}} but do it later only upon demand? Your code seems to proactively create a {{code|newChild}} at every emulated {{code|#invoke}}. If you instead, created a dummy table with a metatable and pass that in, you could wait until the target code actually tries to reference fields from the dummy frame and only {{em|then}} create the {{code|newChild}} upon demand and return values from there. This way if the target module never uses the dummy frame object, {{code|newChild}} is never actually called. You could also try and monkey patch the {{code|mw.getCurrentFrame}} to return the same dummy frame object fixing those situations I mentioned above. Of course if the target module does try to use its frame object, then you will be forced to call {{code|newChild}} and provide one so the number of iterations would be limited then. Since most modules at least attempt to use the frame {{code|args}}, you will likely want to handle that yourself avoiding the {{code|newChild}} call. You will likely want to handle {{code|getTitle}} and {{code|getParent}} (for its own {{code|args}}) too but in other cases you could punt to {{code|newChild}} upon demand. The code would likely be pretty tricky but it should work fairly well (except for possible initialization block issues referenced earlier). Just some ideas. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 18:30, 13 July 2025 (UTC) :::: Thank you again, [[User:Uzume|Uzume]]. As for the nomenclature, I might agree that “magic” is a bit creative, but it has the advantage of being short. Any other solution was lengthier. But I am definitely open to suggestions, as long as they are coherent with the rest of the names. As for “consolidate my <code>#invoke</code> code” and “encapsulate <code>expandTemplate</code> and <code>callParserFunction</code>”, I am not totally sure I understood what you mean. As for creating a metatable and passing that, there is no way that the target module does not access its <code>frame.args</code> metatable in functions like <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code>, so at least that will have to be a “fake” parameter table. I was thinking that I could create a single <code>:newChild()</code>, create a metatable, redirect all its fields except <code>frame.args</code> to that single child frame, and use a normal (always changing) table for <code>frame.args</code>. How does this sound? You might have just given me an idea to experiment with. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:58, 13 July 2025 (UTC) :::::@[[User:Grufo|Grufo]]: By encapsulate I mean make a function or something so there is only one copy of the code to maintain and have everything that needs to accomplish that feat use that function (or class object, etc.). Your idea sounds like an interesting starting point but I do think you are going to run into many weird corner cases and you need to be {{em|very}} meticulous and methodical with your design and implementation. And I question the need for {{code|newChild}} if you are not planning to capture the args in an actual parser frame (because you keep changing them without a {{code|newChild}} for every change). What you are suggesting is very much like the Fandom {{code|makePseudoFrame}} (which does not bother with {{code|newChild}} {{em|because}} it does not capture the args in an actual parser frame). Of course doing that presents issues if the target module tries to call back into parser as the parser will then not know about those uncaptured args. Instead of "magic" why not just "pf" or "parserfunc" or some such. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:12, 13 July 2025 (UTC) :::::: @[[User:Uzume|Uzume]]: <code>:newChild()</code> would be needed because the callback module might want to access other fields of the frame object (e.g. <code>:callParserFunction()</code>, or <code>:getParent()</code>, and in this way it will have the entire suite of fields ready. These remain constant for the entire duration of this module's invocation, so it makes sense that they always refer to a single child frame. The only thing that the callback modules can see changing is their <code>frame.args</code> field. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 13 July 2025 (UTC) :::::::@[[User:Grufo|Grufo]]: Even if they remain constant, why bother with {{code|newChild}} if you can get them from your own frame? Well the only thing they will see is the changing {{code|frame.arg}} {{strong|if and only if}} that is all they look at. You mentioned the target module might want other fields. What if it wanted say {{code|preprocess}}? The parser does not know about your changed uncaptured args so the {{code|preprocess}} has the possibility of rending incorrectly (e.g., parsing {{param|1}}, etc.) The point is, either capture the args with a real {{code|#invoke}} or {{code|newChild}} {{em|or}} don't and then there is no real need for {{code|newChild}}. Besides the functions themselves, a frame is really only a page name and a set of args. Sure you might be able to capture the title but if you are tweaking the args all the time, it would be very little work to handle the title yourself too. If you handle both, I do not see the point. What does even a single {{code|newChild}} buy you. I say very little under those circumstances. Of course it it is only one call so feel free to explore, but I really do not see the need. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:46, 13 July 2025 (UTC) :::::::: @[[User:Uzume|Uzume]]: There are many little reasons why <code>:newChild()</code> is necessary. For instance in the callback module <code>frame.args</code> should return the parameters passed to the callback module itself, whereas <code>frame:getParent().args</code> should always return the calling template's parameters (I mean the parameters passed to the template that invoked [[Module:Params]]); or <code>frame:getTitle()</code> should return, for instance <code>Module:String</code>, whereas <code>frame:getParent():getTitle()</code> should always return the calling template's name, and so on. As for <code>frame:preprocess()</code>, you are possibly making a valid point (I should test it). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 23:54, 13 July 2025 (UTC) :::::::::@[[User:Grufo|Grufo]]: But you can just pass back your module's parent frame for {{code|getParent}} and you already know the target module's full pagename as you need that to call {{code|require}} so you can easily implement {{code|getTitle}}. Anyway, I have not tested this at all however, I made a first try at creating an {{code|invoke}} function in [[Module:Sandbox/Grufo]]. I am not sure how robust it is but it should spoof {{code|args}}, {{code|getParent}} and {{code|getTitle}} while also monkey patching {{code|getCurrentFrame}} and never creating any frames until the target module attempts to access one of the other fields. Then it calls {{code|newChild}} and updates all the fields to stop spoofing things but just passing calls to the on demand created child frame. This will still have a 100 frame limitation if the target module uses those fields, but if it sticks to just those three that I have spoofed, it should never hit any such limit. It might be possible to spoof some of the other fields but they do not seem to be in much demand besides the ones that probably require calling back into the parser anyway. It also can do nothing about load detection in the target modules initialization block. It certainly has some key caveats but I think this should work for the vast majority of cases and be a little lighter on resources than doing many actual {{code|#invoke}} calls. Let me know what you think and if you try it out, etc. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 01:17, 14 July 2025 (UTC) :::::::::: Thank you for your code, [[User:Uzume|Uzume]]. I have not tested it yet, but it seems to me that on demand (i.e. delayed) it creates a child frame for each callback, am I wrong?. This means that with functions like <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> it will hit the &lt; 100 limitation for sure, because these callbacks can never ignore the <code>frame.args</code> metatable. P.S. I started playing around with my solution, but so far I did not find a way to make the methods of the pseudo frame object work (none of them). Only the fields work. This happens because of [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 this restriction]. So I will have to find a way somehow to bypass it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:04, 14 July 2025 (UTC) :::::::::::@[[User:Grufo|Grufo]]: No, that is not how it designed to work. It creates the {{code|frameSpoof}} and passes that instead. It is filled with fields that are punting stub functions that will call {{code|newChild}} and then rewrite the stub functions to other stub functions that will use the created {{code|newChild}}. This way if the target module does access one of the unspoofed fields, {{code|newChild}} will be called from inside the target module by one of the punting stub functions but only once. But before I am done creating the {{code|frameSpoof}}, I overwrite the fields I want to spoof including {{code|args}}, {{code|getParent}} and {{code|getTitle}}. So target modules that only use those three fields will use those spoofed values and {{strong|never}} have {{code|newChild}} called. In fact, technically the target module is calling {{code|newChild}} when it calls one of the punting stub fields that are not spoofed. This is why the {{code|newChild}} is delayed. It is also why target modules that do not touch those other punting fields will never actually call {{code|newChild}}. We cannot control what the target module will do but we {{em|can}} respond to what it does do. So I wrote it inside-out which makes the code a little weird and maybe hard to follow. Once {{code|frameSpoof}} is completely constructed with its one-time punting stubs and three spoofed fields, I monkey patch {{code|getCurrentFrame}} to return my {{code|frameSpoof}} and then call the target module function and then immediately unpatch it before returning the value from the call to the target module function. Remember, you are not just spoofing the target module function. You are spoofing that and {{strong|everything}} it calls including other modules it loads and calls via {{code|require}}, etc. Your module's main use cases make it lean towards being used with other modules that have functions with fairly simple functionality (otherwise why call them repeatedly?). If those target module functions are simple enough to not trigger one of the {{code|newChild}} stubs in {{code|frameSpoof}} (i.e, one of the punt stubs vs. the spoof fields), they never need do any punting to {{code|newChild}} at all. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 06:46, 14 July 2025 (UTC) :::::::::::: @[[User:Uzume|Uzume]]: I am amazed. But I have to admit that you lost me there. I will probably have to just study your code. But just as a quick understanding, if I were to implement <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> using your solution, and then I were to launch the following code (which calls {{mfl|string|replace}} 101 times), :::::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params|new| imposing|101|| filling_the_gaps| mapping_by_replacing||true|1|strict| mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false| for_each|[$#::$@]}}</syntaxhighlight> :::::::::::: would I hit the &lt; 100 parameters limitation? --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 14 July 2025 (UTC) :::::::::::::@[[User:Grufo|Grufo]]: Based upon my understanding and having studied [[Module:String]] (so I know it hardly touches its frame for anything other than {{code|args}}), I believe you should not hit such a limit (although you might hit others I am not sure). But of course such things need testing. I did some basic testing to make sure it appears to work in general. But I certainly did not test it to that extent. Also it {{em|really}} needs more input validation, etc. For example, right now, I could pass in some nasty things to {{code|modargs}} that are not strings, etc. But assuming one does not do anything crazy, I believe it should handle your situations fairly well. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:04, 14 July 2025 (UTC) :::::::::::::: @[[User:Uzume|Uzume]]: Thank you. Some personal commitments got in the way, and I won't be free until the beginning of August (so I will just do ordinary admin tasks on Latin Wikipedia for the next days). But I want to get to the bottom of this. In the meanwhile, if you find a solution that never hits the &lt; 100 limitation, please make a whistle. The ideal would be that we found a way to create a <code>:newChild</code> only once. But unfortunately, due to [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 this restriction] using a custom metatable instead of the original frame won't work. And honestly at the moment I am in lack of frash new ideas. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:55, 16 July 2025 (UTC) :::::::::::::::@[[User:Grufo|Grufo]]: Yes, I too noticed how the Lua frame object methods created by {{code|newFrame}} use their private {{code|checkSelf}} function to validate the passed in frame table {{code|self}}arguments preventing anyone from calling those functions without with passing in the exact table they were created for. This is probably why {{code|makePseudoFrame}} creates a bunch of stub functions like [[CentralWikia:dev:Module:FrameTools#L-76--L-84|this]] that punt/redirect calls to a passed in real frame object. It is also in part why I do something similar with regard to creating punting stub functions as well as replicate the {{code|checkSelf}} style code to propagate errors. That said, even without the {{code|checkSelf}} restrictions, passing in different frame objects probably would not work anyway due to the way they {{code|newFrame}} creates a [[closure (computer programming)|lexical closure]] for each frame method and each depend on their upvalues. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 07:32, 17 July 2025 (UTC) :::::::::::::::@[[User:Grufo|Grufo]] You recently mentioned Postel's [[robustness principle]], in an entirely different context, but to that end I thought I would mention some things. I have improved my {{code|invoke}} emulation code at [[Module:Sandbox/Grufo]] including better monkey patching of {{code|mw.getCurrentFrame}} to allow it to be seen by the target module initialization block (i.e., {{code|require}}), completely saving and restoring {{code|package.loaded}} so it appears {{code|require}} was never called, and perhaps most importantly sanitizing the given {{code|modargs}}. Remember {{code|#invoke}} and {{code|newChild}} will provide a target module with {{code|frame.args}} that have stringent requirements. The passed in {{code|modargs}} are spoofed to the target module without going through such things so they need to emulate them closely or the target might get weird things it is not expecting, e.g., the target module might check {{code|args[1]}} but the given {{code|modargs}} might have a value like {{code|args['1']}} which would not be seen as the same (conversely {{code|modargs}} might have {{code|args[1.2]}}). BTW, I tried creating a proof of concept at [[Module:Params/sandbox]] by loading my {{code|invoke}} via {{code|require[[Module:Sandbox/Grufo]]}} and I ran into some major problems. [[Module:Params]] has {{strong|serious}} bugs. I wrote [[Module:Sandbox/Grufo]] to use [[mw:LUAREF#strict|strict]] to avoid inadvertent global reference bugs but it exposes them in [[Module:Params]]. You should really at least test with {{code|strict}} as you never know what your target modules may or may not call. If they are buggy and do not use it, you will break them if you use it, however, if they use it and your code is buggy they will break your code. So even if you chose to not use it in [[Module:Params]] itself, you should really consider testing with it turned on early to expose as many of your bugs as possible so that you won't have such things and the target module cannot break you by exposing such with {{code|strict}}, etc. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 04:57, 21 July 2025 (UTC) :::::::::::::::: @[[User:Uzume|Uzume]]: Thank you a lot for helping with this and other modules. You will have to wait a few more days for me to have a look at [[Module:Params/sandbox]]. In the meanwhile I added the <code>strict</code> directive to [[Module:Params]], but [[Special:Diff/1297865432/1302040393|these]] were all the bugs I could find. Please let me know if you see any other bug! --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 01:16, 23 July 2025 (UTC) :::::::::::::::::@[[User:Grufo|Grufo]]: That is great. Thank you for fixing your issues related to [[mw:LUAREF#strict|strict]]. I was having problems trying to figure out what were the right fixes for those issues. I did find one more bug: [[Module:Params#L-1910]] {{code|fname}} should be {{code|mname}}. But this is related to your {{code|#invoke}} emulation paths so necessarily it will get fixed when converting to my own {{code|#invoke}} emulation code. To that end, I ported my sandbox proof of concept changes using my {{code|invoke}} emulation to the new active code (i.e., with your {{code|strict}} fixes) so now the proof of concept works and you can "look at" it when you get time. For example, this works: {{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|1025||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|1025||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}} Cheers, —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 13:38, 23 July 2025 (UTC) :::::::::::::::::: @[[User:Uzume|Uzume]]: Good catch again! [[Special:Diff/1302041492/1302137674|Fixed]]! :-) --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 16:11, 23 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: That is an easy answer. MediaWiki owns the parser and the parser {{em|knows}} about the entire parse tree (well eventually it does anyway otherwise it cannot yield a completely parsed page and that is really the parser's main job). So even though you can use {{code|newChild}} to {{em|create}} a parser frame object, you do not really know when it is safe to {{em|destroy}} it and so Scribunto does not provide access to a frame destructor for frames. The parser {{em|does}} know so it merrily goes along creating and destroying them. If you call {{code|#invoke}} 200 times, so long as there is no dependency requiring the frames to continue to exist, MediaWiki destroys them (if you created a tree of recursions where each frame created more frames there would be dependencies and the frames would have to live longer). In this way, so long as nothing hits imposed resource limitations all is good. Since the main parser is unlikely to need {{strong|many}} frames at any single point in time, there is a limit imposed on them and you found it: 100. Since you cannot pass back unparsed text from Scribunto, I imagine the parser will quite quickly destroy all the frames you created with {{code|newChild}} upon exit of the {{code|#invoke}} to your module. This means you can batch such things, e.g., you could assume you can create 50 {{code|newChild}} frames without issue, then you could have some code that processes no more than 50 iterations and have your main code {{#invoke}} back into your own module where that entry point just does the 50 limit max and returns. Then your main code could get control again and keep doing this until the request is complete no more than 50 at a time. In fact the {{code|callParserFunction('#invoke', ...)}} route could be views as a "do only one iteration at a time" batch processor. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:00, 13 July 2025 (UTC) :::: Now it is all clear. Thank you! --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:04, 13 July 2025 (UTC) === Evaluation of <code>#invoke</code> emulation === @[[User:Uzume|Uzume]]: No deep code analysis yet, but if now I run [[#speed-test-1|these tests]] again your solution seems even faster than the original solution with <code>:newChild()</code>! Would you mind replacing [[Special:PermanentLink/1302784329#L-731|this line]] in [[Module:Params/sandbox]] with the actual <code>invoke()</code> function (i.e. no <code>require</code>)? P.S. I [[Special:Diff/1302113607/1302784329|double checked all the steps]], and that led me to restore <code>tostring(tmp)</code> at [[Special:PermanentLink/1302784329#L-1508|line 1508]]. That directive was born from [[Module talk:String#Protected edit request on 18 October 2024|this discussion]]. I did not check if your <code>invoke()</code> function already stringifies the returned value (in which case, it shouldn't, because as you can see, if it is compatible with a number we choose the number). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 12:48, 27 July 2025 (UTC) :@[[User:Grufo|Grufo]]: I do not mind pasting {{code|invoke}} directly into the sandbox, however, since you had some trouble understanding it, I instrumented it with long blocks of comments. I am not sure all of those are the best thing for directly pasting into the sandbox. Remember [[Module:Sandbox/Grufo]] is basically a sandbox itself and I made many improvements to it there. Yes, I noticed that extraneous {{code|tostring}} but my {{code|invoke}} emulates a {{code|#invoke}} so it does in fact always return a {{code|string}}. In fact there is a strange quirk there that I emulate as well. When the target module returns multiple values in its returned expression list, {{code|#invoke}} will treat them as a sequence and turns them all into strings and concatenates them. This means that if there are intervening {{code|nil}} values, they are seen as the end of the list. I emulate this by storing the return values into a table, iterating the table with {{code|ipairs}} putting each value through {{code|tostring}} and then calling [[mw:LUAREF#table.concat|table.concat]]. So [[Module:Sandbox/Grufo#L-186]] is meant to emulate [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/854851ee9bd1863585a0474a1b5b284d48fc5bad/includes/Engines/LuaCommon/lualib/mw.lua#L536 includes/Engines/LuaCommon/lualib/mw.lua line 536]. {{highlight|Anyway, the TLDR, part is that {{code|#invoke}} guarantees a string return value so my {{code|invoke}} emulates that and there is no need for a redundant {{code|tostring}}}}. Your {{code|#invoke}} emulation with a preemptive {{code|newChild}} did not do this right and that is why you previously needed the extra {{code|tostring}} (i.e., it should be considered a part of your {{code|#invoke}} emulation which I am replacing). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:00, 27 July 2025 (UTC) :@[[User:Grufo|Grufo]]: I pasted in a working copy of my {{code|invoke}} code so the sandbox no longer requires [[Module:Sandbox/Grufo]] and should work stand-alone again. However, if further development on that code is required, it will be a major pain to always keep them in synchronization. I did {{strong|not}} strip out the {{code|noemu}} {{em|real}} {{code|#invoke}} code (which can be easily tested by adding {{code|true}} to the end of the function call arguments) nor did I remove the overzealous and copious comments I put in there for your benefit. In production code, you might want to consider whether to keep such things so I cannot currently recommend you just accept the current sandbox {{em|as is}} but it should still be a good proof-of-concept for evaluation purposes as likely you will want to do something similar with some cleanup. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:58, 27 July 2025 (UTC) :: Thank you a lot, [[User:Uzume|Uzume]]. Got it. Don't worry about the comments, that is just a sandbox and they are very helpful there. We will do a cleanup for the final version. As for further developments, even if it is pasted inside a large module, it is still an independent function; it should still be easy to experiment separately with it in the future. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 16:13, 27 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: As a reminder, {{code|newChild}} will not be called so long as the target module never uses anything from the {{code|frameSpoof}} that I actively spoof, i.e., {{code|getParent}}, {{code|getTitle}} or {{code|args}}. Here are some examples to demonstrate such:{{olist|1={{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}}|2={{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}}|3={{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|99||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|99||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}}}} In the first case, the target module never touches anything that is not spoofed so it works. The second fails because it adds {{para|tag|nowiki}} to the call and [[Module:Ustring]] wraps the output in the given tag by calling {{code|extensionTag}}—something that is not currently spoofed so it causes those to fallback to using {{code|newChild}}. The same is true in the third example, however it does not fail because it is just under the 100 frame limit. It should be noted that this falls back on a case-by-case basis. I cannot think of any really good examples off the top of my head but if you could say alternate the parameters to the target (i.e., along the lines of even vs. odd, etc.) then it would only call {{code|newChild}} in the situations where the target touched non-spoofed fields. In the odd—even case, one might effectively double the limit because it would only be using {{code|newChild}} half the time. You know [[Module:Params]] much better than I do so perhaps you can come up with some more interesting test cases. It also shows that we might be able avoid the above issue by extending {{code|frameSpoof}} by writing a spoof for {{code|extensionTag}}. I believe that might actually be possible. I know some extension tags do in fact call into the parser (e.g., {{tag|ref|o}} does this to render wikitext with its contents) but I {{em|believe}} they carry no parser context when they do (i.e., each is effective a new parser instance and doing things like {{tag|ref|content={{param|1}}}} is meaningless). I would have to research and test such. The same can be said for the other unspoofed fields (e.g., virtually nobody uses {{code|argumentPairs}} but I think it could be easily spoofed; I just did not bother to spend time on it). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 20:49, 27 July 2025 (UTC) ::::@[[User:Uzume|Uzume]]: I am still unsure whether including [your “frame spoof” code] in [[Module:Params]] [is a good idea] or not. Among the reasons there is that it is not perfect and it adds a lot of lines of code. The other thing that makes it look like a non-urgent fix is the fact that so far no template hit the “> 99 parameter limit” using [[Module:Params]], and when that were to happen, it will still be possible to write <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code> – although I am pretty sure at that point this discussion will be re-opened. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:46, 29 September 2025 (UTC) :::::@[[User:Grufo|Grufo]]: I agree the code is not particularly small nor even easy to understand, however, I did try to make it as straightforward as possible. This is why I originally put it in [[Module:Sandbox/Grufo]] and had [[Module:Params/sandbox]] refer to it much like {{code|makePseudoFrame}} from [[CentralWikia:dev:Module:FrameTools|Module:FrameTools]]@[[Fandom (website)|Fandom]] might have been used. Remember, {{strong|you}} were the one that {{em|insisted}} on pasting that directly into [[Module:Params/sandbox]]. I personally believe you and [[Module:Params]] are hardly the only ones interested in an efficient <code>{{tlm|#invoke:}}</code> emulation. Towards that end, I believe it makes more sense to place that code within its own Scribunto module and have [[Module:Params]] reference it. You could spearhead a new stand-alone module, but that might be hard to argue due to its restricted current use case. So instead, I recommend creating a submodule like [[Module:Params/invoke]] and let it grow organically from there. Maybe one day someone else will be interested enough to make this into a stand-alone module that can be moved out from under [[Module:Params]]. At least that is my take on what should be done about it and I hope that answers your question as put to me. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:00, 29 September 2025 (UTC) :::::: Hi [[User:Uzume|Uzume]]. Creating a separate module is a minor issue. We can definitely do that, especially if other modules can benefit from your “frame spoof” solution – though, as long as [[Module:Params]] will be the only module that depends on it, that will be the only module able to spot (and suffer from) possible bugs. The question that bothers me however is: Can it be made perfect? Can it be made so that it can always deal with > 99 parameters? I like your solution because the code seems to run even faster than the current code. However it is not a minor change, and if currently nothing suffers from that problem I would be inclined to let us take more time to search for ideal solutions. And maybe invite other Lua developers to this discussion as well. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 21:49, 29 September 2025 (UTC) :::::::@[[User:Grufo|Grufo]]: Well, my "frame spoof" based emulation is not specifically limited by 99 frames as {{lang|la|per se}}. It is limited to ~99 frames where the target uses something beyond the basic "frame spoof" which then punts to using {{code|newChild}} and thus the limit. Everything has resource limits. It just depends on what resources are used. If the target does not use any frame fields beyond those provided by the basic "frame spoof", {{code|newChild}} is never used and so there is no 99 frame limit although I am sure there is some other resource limitation somewhere else eventually. If the target {{em|sometimes}} uses those fields beyond those provided by basic "frame spoof", then the emulation will only {{em|sometimes}} fallback to using {{code|newChild}}. Under such a situation, it would be limited to how many {{em|sometimes}} such were used. As an example, if you have a target that only uses {{code|newChild}} fields when some given argument is even (vs. odd), then the emulated frame limit would effectively be about twice the 99 {{code|newChild}} frame limit. If you know specifically which fields are falling back to {{code|newChild}}, it might be possible to improve the emulation to implement such in the "frame spoof", however, some will be extremely difficult to emulate correctly as they imply a call back into the parser which is hard to do without an actual parser frame. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 23:27, 29 September 2025 (UTC) :::::::One extremely crazy idea I just had would be to attempt to hang on to any output/side effects the target might create and then if the target uses something beyond the basic "frame spoof", instead of punting to {{code|newChild}}, backtrack/unwind the call to the target and re-execute using a real {{tlm|#invoke:}} off the parent frame. That should not have the ~99 frame limitation but would then cause the code to slow down (since as per your testing such is slower). That said, it might be hard to capture all the potential side effects of target execution in order to backtrack. I might think about that some more (obviously the main side effect of target execution is its output toward the page being rendered). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 23:27, 29 September 2025 (UTC) :::::::: All clear. Please, feel free to run all the experiments you want here. You can create other sandbox submodules if you need. If only emulating <code>#invoke:</code> from modules were a more widespread necessity, we could also think about asking MediaWiki's backend developers to remove [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 all those ckecks] that forbid us to create a fully-functional pseudo-frame object. But here we are at the moment. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:10, 30 September 2025 (UTC) :::::::::@[[User:Grufo|Grufo]]: The checks are not really the main issue and in fact they are probably a good thing. The real problem is the cost of a true {{tlm|#invoke:}}. If the overhead was not so high there would be little reason to emulate it. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 10:07, 30 September 2025 (UTC) :::::::::: @[[User:Uzume|Uzume]]: As for the cost of a true <code>{{mwl|#invoke|}}</code>, I agree. Those checks however are what forbids us to create a simple Lua table that emulates the <code>frame</code> object (“pseudo-frame”) and call the native methods on such a table. If that were possible we would have a different discussion right now. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:59, 30 September 2025 (UTC) :::::::::::@[[User:Grufo|Grufo]]: Actually, no that is not true. It is true the checks stop such use but they are only a warning/error message. The real issue is the real parser frame that is passed back into the parser. The Lua functions are going to use the upvalue anyway. Checking the passed in {{code|self}} value matches the upvalue is probably a good thing ensuring calls are not made in error. Technically, those functions do not even need the passed in frame parameter (much less its argument value) to function properly. The check just ensures the caller isn't attempting something improper. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:13, 30 September 2025 (UTC) :::::::::::: @[[User:Uzume|Uzume]]: Got it. Then I am short of ideas for now. If you think your solution, even if it only partially solves the “> 99 parameters problem”, is better than the current <code>:newChild()</code>, we can think of using it. We can follow your suggestion of creating a [[Module:Params/invoke]] submodule – or, if you have any idea of other modules that might be interested in the same machinery, we could also create a top-level [[Module:FrameSpoof]]. I just updated [[Module:Params]] today (with totally unrelated things), so let's wait some time between updates. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:30, 30 September 2025 (UTC) ::::::::::::: @[[User:Uzume|Uzume]]: I have a curiosity (but just if it does not bother you). Previously we talked about how a module can detect whether it is called via wikitext or via Lua. I created a dummy <code>foobar</code> function at [[Module:Sandbox/Grufo2]], then I called it via {{mfl|params|concat_and_invoke}} at [[Module:Params/testcases/sandbox]]. Would you be able to edit such a <code>foobar</code> function so that it returns “Yay!” if it detects it is being called via {{mwl|invoke|}} and “Nay!” if it detects it is being called via {{mfl|params|concat_and_invoke}}? --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 01:48, 3 October 2025 (UTC) ::::::::::::::@[[User:Grufo|Grufo]]: Yes, that is a very simple request. There are a number of ways to detecting such things. One way that is very difficult to get around is to detect how the Scribunto module is loaded. [[Module:Sandbox/Grufo]] gives good examples of such detection splitting out {{code|require}} and {{code|mw.loadData}} vs. {{code|#invoke}} and the {{code|console}}. Anyway, I made the edit you requested via the simplest means (in this case testing {{code|...}} during the module initialization), see [[Special:Diff/1314758676/prev|1314758676]]. Note, this does not specifically detect if it is loaded from wikitext or via Lua as one {{em|can}} call a real {{code|#invoke}} from Lua using <code>[[mw:LUAREF#frame:callParserFunction|frame:callParserFunction]]</code> —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 02:50, 3 October 2025 (UTC) ::::::::::::::: Thank you a lot, [[User:Uzume|Uzume]]. Luckily there is always solution #3 for those picky modules that check (I just edited [[Module:Params/testcases/sandbox]]). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:28, 3 October 2025 (UTC) ::::::::::::::::@[[User:Grufo|Grufo]]: Yes, that is exactly it. With the simplistic and straightforward {{code|newChild()|lua}} based emulation implemented in {{mfl|params|concat_and_invoke}} there are also many other ways to detect such. For example, since such an implementation is loading the target module via {{code|require()|lua}}, its initialization block is cached and only executed once. Package functions in the target module could change variables in either the global or target module spaces and notice their package functions are being executed multiple times. Perhaps a bigger issue is with target module code that uses <code>[[mw:LUAREF#mw.getCurrentFrame|mw.getCurrentFrame]]</code> as that will {{strong|not}} return the frame value passed to the target package function (i.e, that you are creating via {{code|newChild()|lua}}). You balk at the code size of my "frame spoof" based emulation but the majority of its size is actually comments—most of which I added to help you understand how it works or why it is implemented a certain way. These could be removed or at least significantly pared-down. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 12:54, 3 October 2025 (UTC) ::::::::::::::::: Thank you, [[User:Uzume|Uzume]]. I promise you that my next message to you will be after having studied your code. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:35, 3 October 2025 (UTC) ::::::::::::::::::@[[User:Grufo|Grufo]]: Towards that end I recommend you read [[Module:Sandbox/Grufo]] as that has the most up-to-date version of my {{code|pkgAPI.invoke()|lua}} function. I am sure you will have many questions. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 13:50, 3 October 2025 (UTC) == Not a sustainable approach to templates == @[[User:Grufo|Grufo]]: On the one hand, this is cool. I like programming, and [[Module:Params]] is obviously super powerful. But it's not a good choice for a place like Wikipedia. It's simply too complex. Basically, you've created another programming language. When I see stuff like <code>entering_substack</code>, I think of [[Forth (programming language)]]. :-) The main problem is: Nobody but you will be able to maintain a template like [[Template:Universal page list with custom separators]]. But Wikipedia is based on collaboration by (mostly) non-expert volunteers. We need code that is readable and writable by a large number of users. We should stick with Lua modules and Mediawiki templates, and the code should be kept relatively simple. I'm sorry, and I admire your work on [[Module:Params]], but I don't think it's going to be a good fit. — [[User:Chrisahn|Chrisahn]] ([[User talk:Chrisahn|talk]]) 14:22, 16 October 2025 (UTC) == Copied discussion == @[[ಬಳಕೆದಾರೆ:Grufo|Grufo]]: I stumbled on this copied talk page. I thought you might be interested if you ever want to come back and read some of this. —[[ಬಳಕೆದಾರೆ:Uzume|Uzume]] ([[ಬಳಕೆದಾರೆ ಪಾತೆರ:Uzume|ಪಾತೆರ್ಲೆ]]) ೦೫:೪೮, ೧೩ ಜುಲಾಯಿ ೨೦೨೬ (IST) 4epj7mo5qenrfafs592g7vqj52plfct 362743 362732 2026-07-13T09:29:07Z Grufo 6930 /* Copied discussion */ 362743 wikitext text/x-wiki == New function <code>self</code> == I have added a new function to the module, &#123;&#123;[[Module:params|#invoke:params]]|[[Module:params#self|self]]&#125;&#125;, however I am not sure whether the most idiomatic name for it is <code>self</code> or <code>title</code> (especially considering that <code>self</code> has a special meaning in Lua). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:36, 27 September 2023 (UTC) :@[[User:Grufo|Grufo]]: I would prefer a different naming. Based upon magic words like {{tlm|PAGENAME}} and friends, things along the lines of <code>PARENTNAME</code>, <code>TEMPLATENAME</code> (sadly we already have a {{tl|TEMPLATENAME}} with a slightly different meaning), <code>INVOKERNAME</code> or similar come to mind, along with the possibilites of things like <code>CHILDNAME</code>, <code>MODULENAME</code>, <code>INVOKEENAME</code> or similar; potentially with modifiers for other encodings ''a la'' {{tlm|PAGENAMEE}} and [[mw:Manual:PAGENAMEE encoding#Encodings compared|comparison of page title encodings]], etc. (e.g., by returning [[mw:Extension:Scribunto/Lua reference manual#Title objects|mw.title:partialUrl()]] or similar), not to mention other options in line with things like {{tlm|FULLPAGENAME}}, {{tlm|FULLPAGENAMEE}}, etc. That said, perhaps those names are not really the best either and it would be better to stick to naming closer to Scribunto naming along the lines of <code>parentPageTitle</code>/<code>modulePageTitle</code> and stick to modifiers provided by <code>mw.title</code> object and/or <code>mw.url</code> API like <code>partialUrl</code>, <code>queryEncode</code>, <code>pathEncode</code>, <code>wikiEncode</code>, <code>anchorEncode</code>. Incidentally, I have often considered developing a Scribunto replacement for base (or even all the extensions in the default and/or WMF MediWiki packaging) magic words and then potentially extending it from there. This begs the need for these types of things more generally but I digress. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:51, 6 March 2024 (UTC) :: @[[User:Uzume|Uzume]] Sorry for my very late reply. Your suggestions would be <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKERNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CHILDNAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|MODULENAME}}</syntaxhighlight>, or <syntaxhighlight lang="wikitext" inline>{{#invoke:params|INVOKEENAME}}</syntaxhighlight>. These would break the convention used for function names in this module, and also would not be so immediate to understand (i.e. if template <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> ''invokes'' this module I would expect “INVOKENAME” and the other names you propose to return <code>Module:Params</code> instead of <code>foobar</code>). There is a convention used by many programming languages according to which the parameter zero is the name of the routine executing the code (e.g. in [[Bash]] <code>$<nowiki />1</code>, <code>$<nowiki />2</code>, <code>$<nowiki />3</code>, … are the parameters, whereas <code>$<nowiki />0</code> is the name of the script or the name of the subroutine, much like our <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>). However in these languages parameters can only be non-zero positive numbers, whereas in template syntax <code>0</code> can also be a parameter name (e.g. <syntaxhighlight lang="wikitext" inline>{{foobar|0=hello|1=world}}</syntaxhighlight>), so another solution needs to be found. There used to be an <code>arguments.callee</code> property in JavaScript with a similar meaning, but [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee today is deprecated], and if we named our function <syntaxhighlight lang="wikitext" inline>{{#invoke:params|CALLEENAME}}</syntaxhighlight> I believe it would create confusion in redirected templates. The name “self” is what for me comes the closest to “parameter zero” in those languages that use the latter for the same purpose. And so “self” inside <syntaxhighlight lang="wikitext" inline>{{foobar}}</syntaxhighlight> is <code>foobar</code>. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 22 May 2024 (UTC) :::@[[User:Grufo|Grufo]]: To me <code>self</code> tends to lend its meaning from Lua in much the same way as as <code>this</code> does in C++, namely an [[object (computer science)|object]] reference (although in C++ these are always [[class-based programming|class-based]] and in Lua they do not have to be as they could be [[prototype-based programming|prototype-based]], etc.). It is true that in MW "title" has several meanings but its most common meaning is a textual name of a {{em|page}}, that said I would try to avoid it based on things like [[mw:Manual:Modeling pages|Manual:Modeling pages]]. That said page "title" and <code>PAGENAME</code> tend to be the name of a page without a namespace, as opposed to <syntaxhighlight lang=lua inline>frame:getTitle()</syntaxhighlight> and <code>FULLPAGENAME</code>, etc. You asked how people felt about the naming of the current <code>self</code> invocation target and though I am not a fan of "self", I do think it is better than anything with "title" in its name. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 10:16, 23 May 2024 (UTC) :::: It's true I asked, but my concern was not about how understandable the term is, but about the fact that “self” has a peculiar meaning in Lua. And although this still holds true, it is also true that this module is not meant to be called by other modules (i.e. it is not meant to be used in Lua), but it is meant to be called by templates, where “self” has no special meaning whatsoever (plus, template writers are required to know nothing at all about Lua, and maybe one day modules will be written in more languages other than Lua). And ''even if'' a template writer knows about Lua, <code>self</code> would still make sense (i.e. the “Lua-style ''self'' from the point of view of a template is the template itself”). If you mention words that are already in use, they would carry the reference they currently have (e.g. “title” would refer to the transcluding page, not the transcluded template), so we do need to invent new words that carry no references, since no magic word or template currently offers the same functionality. For me the only possible contender would be <code>callee</code> (but see what I wrote earlier about the case of redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:42, 23 May 2024 (UTC) :::::Be verbose to avoid any confusion, it costs you nothing. How about calling_template_name? [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 11:20, 23 May 2024 (UTC) :::::: But that would be very confusing! This function is meant to be used in transcluded templates (otherwise one uses<syntaxhighlight lang="wikitext" inline>{{FULLPAGENAME}}</syntaxhighlight>); and if template <syntaxhighlight lang="wikitext" inline>{{foo}}</syntaxhighlight> calls <syntaxhighlight lang="wikitext" inline>{{bar}}</syntaxhighlight>, and the latter contains <syntaxhighlight lang="wikitext" inline>{{#invoke:params|self}}</syntaxhighlight>, we get <code>bar</code>, which is the ''called'' template, not the ''calling'' template (which instead would be <code>foo</code> – of course, technically the called template is also ''invoking'' a module, but users need to know nothing about Lua and modules for using <syntaxhighlight lang="wikitext" inline>{{#invoke:params}}</syntaxhighlight>). It is not a coincidence that in JavaScript the same functionality was called <code>arguments.'''callee'''</code> (and not <code>arguments.'''caller'''</code> – but again, “callee”/“called” create confusion in redirected templates). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:08, 23 May 2024 (UTC) :::::::In your example, template {{tl|bar}} is calling {{mlx|params|self}}, so {{tl|bar}} is the calling template (of your function), and its name is calling_template_name. It could be this_template_name as well. The word 'self' is usually used for the very object (with methods and stuff), not only its name. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 13:39, 23 May 2024 (UTC) :::::::: <code>this_template_name</code> would also be possible. Let's see if others prefer it to <code>self</code>. Contra: although the funcion is meant to be used in templates, nothing forbids to use it in non-transcluded pages, wehere there is no such thing as “this template”; or imagine the page <code>Template:Foobar/doc</code> using <code>this_template_name</code> for referring to itself instead of the actual template it is documenting (i.e. <code>Template:Foobar</code> – that would also create confusion with {{tl|TEMPLATENAME}}). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 21:09, 23 May 2024 (UTC) :::::::::this_function_caller, I don't think it can be more precise; self, though, is a bit confusing when a page transcludes a template invoking a template invoking the function, or any such mumbo jumbo. [[Special:Contributions/68.199.122.141|68.199.122.141]] ([[User talk:68.199.122.141|talk]]) 22:50, 23 May 2024 (UTC) :::::::::I cannot say I like {{code|this_template_name}}. Without doing strange manipulations like {{code|frame:newChild}}, etc. the parent frame should always be the frame that calls {{code|#invoke}}. Even when {{code|frame:callParserFunction('#invoke', ...)}} is called this is normally true as it will either refer to the calling module or if specifically called off the parent frame, the invoker's invoker frame (i.e., a grandparent but the actual invoker frame is hidden then). This is why from the Lua standpoint something like {{code|parent_fullpagename}} probably makes the most sense, however, as you said this is designed to be understood from the template or parent's point of view (the users of which should not need to understand Lua, etc.) and as such there are {{em|way}} too many confusing page names to begin with. To that end, I still like {{code|invoker_fullpagename}}. {{code|full}} should probably be included as {{code|FULLPAGENAME}} includes a prefixed {{code|NAMESPACE}} as this function also returns. If you really like the {{code|caller}} nomenclature then how about {{code|module_caller_fullpagename}} and if you really like the {{code|this}}, how about {{code|this_module_caller_fullpagename}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:06, 11 July 2025 (UTC) :::::::::FYI: {{ml|TEMPLATENAME|main}} now does this same thing too but I am not a fan of its naming either. I personally believe names like {{code|template_name}} or {{code|module_name}} should be considered in situations where they are made to be used with {{code|msg:}} or {{code|#invoke:}}, i.e, the namespace is not prefixed for template or modules but it is otherwise, including for the empty main namespace (for example when you want to transclude a main space page and need syntax like <code><nowiki>{{:mainspacepage}}</nowiki></code> or <code><nowiki>{{msg::mainspacepage}}</nowiki></code> but you don't need such for {{code|{{ns:10}}}} and in a similar fashion you don't need {{code|{{ns:828}}}} for {{code|#invoke:}}. This is exactly what things like {{tlx|TEMPLATENAME}} do because they are designed for constructions like <code><nowiki>{{{{TEMPLATENAME}}|...}}</nowiki></code> (in this case typically from a {{code|/doc}} subpage but one wants it to also render properly from the main template and/or its {{code|/sandbox}} subpage, etc., i.e., everywhere {{code|/doc}} is transcluded from). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:06, 11 July 2025 (UTC) == Wrapper template with pass-thru params == I'm a template writer and have newly discovered this Module, and am still getting on board with it, but have not used it yet. I think it probably will handle some use cases I have, but I'm not quite sure. One case that is typical for me, is a wrapper template with "pass-thru params", that is, the case of a wrapper template A, that calls template B passing thru all or almost all of A's params to B without alteration, and one or two more params with hard-coded values. For a concrete example, consider template {{tl|sfnlink}}. I want to create new wrapper template {{tl|sfnlinknb}}, that will have the identical params that sfnlink has, less param {{para|nb}}; the job of the wrapper, is to pass through all of its params to {{tl|sfnlink}}, and add {{para|nb|yes}} as well. The "pass-thru" part of this seems like the kind of thing I ought to be able to do with Module:Params, but I'm not quite sure. Maybe using <code>for_each</code>? Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 00:09, 3 December 2023 (UTC) :It looks like you have a working implementation using double transclusion and <code>for_each</code> in {{tl|sfnlinknb}} already, but if it's useful as an alternative approach, I just used <code>concat_and_call</code> to do the same thing in {{tl|autnum plain}}: [[Special:Diff/1188117126]]. [[User:DefaultFree|DefaultFree]] ([[User talk:DefaultFree|talk]]) 13:26, 3 December 2023 (UTC) :: [[User:DefaultFree|DefaultFree]], thank you '''so''' much for this. Your solution is infinitely better, and I've rewritten my wrapper using your idea. I had made multiple attempts—you can see the numerous failures at the history of [[User:Mathglot/sandbox/Templates/params_for_each]] and at [[Template:Sfnlinknb]]. At one point, I thought I had it because it worked perfectly at [[Special:ExpandTemplates]], but then I found it didn't work anywhere else—it spit out the correct code (as if it were nowiki'ed), but didn't invoke it, except at ExpandTemplates, for some reason. Then I went off on a tangent, trying to add {{tl|Eval}} in front of the whole thing to get it to execute, and as you saw, I got tangled up in double transclusion, and, oh, what a mess! Yours is so much better, and would make a great addition to the documentation of this Module, either as an example, or as a "Pro tip" note. (You might be interested to see what I did with the (on-page) /doc, the {{no redirect|Template:Sfnlinknb/sandbox|/sandbox}}, and the [[Template:Sfnlinknb/testcases|/testcases]] pages for {{tl|Sfnlinknb}}.) Thanks again, and I owe you one! [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 22:29, 3 December 2023 (UTC) == 15th January 2024: New changes == The [[Module:Params/ChangeLog]] subpage now keeps the record of the most important changes in the module's code. Furthermore four new modifiers – <code>[[Module:Params#mapping_values_by_calling|mapping_values_by_calling]]</code>, <code>[[Module:Params#mapping_values_by_invoking|mapping_values_by_invoking]]</code>, <code>[[Module:Params#mapping_values_blindly_by_calling|mapping_values_blindly_by_calling]]</code> and <code>[[Module:Params#mapping_values_blindly_by_invoking|mapping_values_blindly_by_invoking]]</code> – were recently added to the module. These allow to pass each argument one by one to a custom template or a custom module in order to be preprocessed before further actions. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:07, 15 January 2024 (UTC) == growth and sandboxes == Hi {{ping|Grufo}} - following on from your request over at [[WP:PERM]]. Got a few questions: #Do you know what has recently caused the large growth in calls to this module? Is such a large use necessary? #This module doesn't appear to have a /sandbox; now that it is so heavily used where are changes being validated prior to deployment? Thanks, — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 13:34, 22 April 2024 (UTC) :{{u|xaosflux}}, the drastic usage increase looks to be due to [[Special:Diff/1214727698]]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:42, 22 April 2024 (UTC) ::Numbers should start falling, I've undone the above. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 13:50, 22 April 2024 (UTC) :::FYI to {{ping|Uzume}} — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:19, 22 April 2024 (UTC) ::::@[[User:Xaosflux|Xaosflux]]: Thanks for the heads-up. I just fixed a minor documentation bug. Using something like this module insulated it from potential moves (or someone copying it for as a template, etc.) but there are obviously other ways to fix that issue and I certainly did not mean for it to have such ramifications (I would not want to prevent the author from development; the sandbox still allows such if somewhat more cumbersome). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 14:31, 22 April 2024 (UTC) : Hi [[User:Xaosflux|Xaosflux]]. I have no idea. I tried to find out, but I believe that whoever is responsible for the growth did not follow the suggestion of adding {{Tl|Lua}} to the documentation of the templates that start using this module. So finding out where all the calls come from is hard (btw, someone has to improve the “What links here” special page and allow to list direct transclusions only…). I had planned some important improvements for this module, but I have been very busy in the last months. And as soon as I had a bit of time for the module I found out that I can no longer edit it. Concerning the sandbox: it's not hard to create one, is it? So far every time I posted an update I tested it locally on my machine, but I agree that it would be good to have a sandbox here too. '''EDIT.''' [[User:Primefac|Primefac]] gave the answer while I was writing mine (@[[User:Primefac|Primefac]]: Thank you). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 22 April 2024 (UTC) ::Always happy to help. For the record, I used an insource search to find where it was being invoked, specifically <code>insource:/invoke:params/</code>, as seen [https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&search=insource%3A%2Finvoke%3Aparams%2F here]. [[User:Primefac|Primefac]] ([[User talk:Primefac|talk]]) 14:19, 22 April 2024 (UTC) ::I've lowered the protection level on this, you should be able to edit again. Suggest you build up a sandbox and incorporate it to the testcases. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 14:21, 22 April 2024 (UTC) ::: Thank you both @[[User:Primefac|Primefac]] and @[[User:Xaosflux|Xaosflux]]! The next changes in the code will pass through a sandbox. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 14:30, 22 April 2024 (UTC) == Ready for general use == Improvements are always possible, but I believe [[Special:Diff/1224926156/1225161147|time has come]] to mark this module as [[:Category:Modules for general use|ready for general use]]. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:52, 22 May 2024 (UTC) == Inverting parameters == At {{tlf|[[WP:RSPUSES]]}}, I needed not <code>|1=key|2=value</code> but <code>|1=value|2=key</code>. I achieved this with <code><nowiki>{{#invoke:params|sequential|mapping_by_calling|duses|values_and_names|setting|i|<br>|list_values}}</nowiki></code> when <code>call_for_each</code> didn't work. Are there plans to add a shortcut like <code>call_for_each_value_and_key</code>? [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 21:56, 4 July 2024 (UTC) : You followed exactly the right way. There are no plans to create a <code>call_for_each_value_and_key</code> function, because that will mean that we will have to create also an <code>invoke_for_each_value_and_key</code> function, a <code>magic_for_each_value_and_key</code> function, a <code>call_for_each_key</code> function, and so on. This module is already quite rich in functions; if new functions will be added in the future it will probably be to add new functionalities, not just syntax sugar. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:56, 6 July 2024 (UTC) == Code link on mobile == {{re|Grufo}} Are you aware that the mobile view looks like this? <pre> ---------------------------------------- | Function | | |----------------------------------| | | | count | | | |----------------------------------| | | ( | | code | | ) | | Num. of arguments 0 | </pre> instead of the proper desktop view like this? <pre> |-----| Function |count| (code) |-----| -------------------------------- | Num. of 0 | | arguments | </pre> Ideally the entire header should be on the same line like on desktop. But the parentheses in the code link are currently a monstrosity on mobile. [[Special:Contributions/174.92.25.207|174.92.25.207]] ([[User talk:174.92.25.207|talk]]) 06:03, 8 July 2024 (UTC) : @[[User:174.92.25.207|174.92.25.207]]: Thank you. I think the quirk is too infobox-specific to be integrated in the {{[[Module:Params/doc/link to the code|./doc/link to the code]]}} template. However [[Special:Diff/1233239047/1233369914|this]] should fix it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:45, 8 July 2024 (UTC) == Minor limitation currently affecting some functions == There is currently a design limitation in the [[:mw:Extension:Scribunto/Lua reference manual#frame:newChild|child frame]] object that affects <code>[[Module:Params#invoke_for_each|invoke_for_each]]</code>, <code>[[Module:Params#invoke_for_each_value|invoke_for_each_value]]</code>, <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> and <code>[[Module:Params#renaming_by_invoking|renaming_by_invoking]]</code>. The limitation affects these functions only when used on a large number of parameters (> 99). For more information see: * {{Section link|Wikipedia talk:Lua/Archive 12|Editing the args metatable of a child frame}} * [[:mw:Topic:Y61qv62t0k0w2b7f|Topic on Extension talk:Scribunto/Flow § Design problem in the frame object]] --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 20:03, 14 April 2025 (UTC) :@[[User:Grufo|Grufo]]: It seems like the best solution would be to avoid your current {{code|:newChild}} hacks and instead do actual {{code|#invoke:}} parser function calls via {{code|:callParserFunction}}. That also solves a number of problems with the current solution (besides the 99 frames limit), e.g., the current "invocation" method does not always work correctly for modules that attempt to detect such things (e.g., ones that test their inbound {{code|...}} to see how the module is being loaded, either as a {{code|#invoke:}} "main" or as a {{code|require}} sub-library module, {{code|mw.loadData}}, etc.). It also allows you to jettison some error code as true {{code|#invoke:}} already throws errors when the function cannot be found, etc. Don't try and reinvent the wheel (I ran into a similar situation with [[Special:Diff/954154594/prev|954154594]]). It also allows you the ability to potentially consolidate your code as your template {{code|call}} interfaces could be moved from {{code|:expandTemplate}} to {{code|:callParserFunction}} with {{code|msg:}} and both {{code|#invoke:}} and {{code|msg:}} could be implemented with your {{code|magic}} functions which already use {{code|:callParserFunction}}. The {{code|invoke}} function of <code>[[Module:Lua call]]</code> is a good example. Most uses of {{code|:newChild}} are typically poorly designed. One probably legitimate use would be to create an artificial parent frame for calling {{code|:callParserFunction}} off of (for modules that look at their parent frame, etc.). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:05, 9 July 2025 (UTC) :: Thank you, [[User:Uzume|Uzume]]. You make a strong point when you talk about modules that detect whether they have been called via <code>require()</code> or <code>#invoke</code>. I did not even know that was possible (how does one do that?). I have been thinking for a while about replacing <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code> in the functions listed above. I have not done it so far because I was hoping to trigger a rethinking upstream on how <code>:newChild()</code> is currently designed. However no discussions have emerged so far as far as I know (and so maybe now it is the time to get rid of <code>:newChild()</code>). At the moment, when facing the bug described here, it is already possible to use <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code> (which is why this did not seem to be an urgent fix). For instance, if we wanted to use {{mfl|string|replace}} to replace spaces with hyphens in values (and forgetting for a moment that we already have <code>{{mfl|params|mapping_by_replacing|...}}</code>), we could already do ::: <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_invoking]]&#124;[[Module:String|string]]&#124;[[Module:String#replace|replace]]&#124;4&#124;%s+&#124;-&#124;&#124;false&#124;...</code> :: or, equivalently, ::: <code>...&#124;[[Module:Params#mapping_by_magic|mapping_by_magic]]&#124;#invoke&#124;values_only_as&#124;3&#124;let&#124;1&#124;[[Module:String|string]]&#124;let&#124;2&#124;[[Module:String#replace|replace]]&#124;4&#124;%s+&#124;-&#124;&#124;false&#124;...</code> :: Interestingly, while <code>#invoke</code> is recognized as a parser function, the same seem not to apply to <code>msg</code>, and so it seems not possible to use the latter in combination with <code>:callParserFunction()</code>. In any case, <code>:expandTemplate()</code> seems to work just fine. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:19, 10 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: I am not sure why {{code|msg}} would not work as a parser function. I wonder if that is also true for {{code|msgnw}} (which is sort of similar to Scribunto {{code|mw.title:getContent()}} because it does {{em|not}} process page source through the main wikitext parser). I wonder if there is an issue with the way you are building your argument list or calling the parser function that is limiting things. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::Anyway, I am not sure about all the ways for Lua modules to detect how they are called but one of the primary ones would be to check {{code|...}} during the execution of the module initialization block (which executes during {{code|#invoke}} before the function call to the its first argument and why it is possible to catch {{em|any}} argument as the function name using a metatable with {{code|__index}} like in <code>[[Module:Ustring]]</code>; oddly enough that also means one can process the frame args {{em|before}} the function name is provided to the module but of course nothing can be returned until later). {{code|require()}} passes in the module's name while Scribunto {{code|#invoke}} does not (imitating command line {{code|lua}} but the frame args are {{em|not}} put into {{code|...}} or global {{code|arg}} so they are always empty/{{code|nil}}; probably because frame args have non-sequential parameter keys). Checking {{code|...}} can be a good way to have the module return a different {{em|package}} table (often denoted as just {{code|p}}) based upon whether it is loaded via {{code|#invoke}} or not. In fact, that style of coding allows one to do away with the awkward leading underscore API functions and even allows the module to {{code|require}} itself during {{code|#invoke}} thereby using its own API while also providing {{em|frame}} wrapper function(s) for {{code|#invoke}} calls from wikitext. The name of the module used during {{code|#invoke}} is of course provided via {{code|frame:getTitle()}} which can be accessed from anywhere, including the module initialization block, via {{code|mw.getCurrentFrame()}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::I created an example module for demonstrating how a module can detect how it is loaded at <code>[[Module:Sandbox/Grufo]]</code>. Feel free to do with it as you see fit. Notice how your {{code|require()}} plus {{code|frame:newChild()}} implementation likely would not work with that construction but a {{code|frame:callParserFunction('#invoke', ...)}} construction would. You should consider which frame to call that off-of though. Frequently it makes more sense to call that off of the parent so that the new invocation has the same parent as where you call it from (i.e., they are effectively "sibling" invocations) as arguments to your module might not be particularly interesting to the module you are invoking (if they are, you should probably pass them to the module directly via its own arguments) but arguments to the parent template would otherwise be lost (due to frame depth; a module can only access its frame and one parent—no grandparents, etc.). I am not sure if it matters which parent frame is available for other parser functions/magic words but I encourage you to consider using {{code|frame:callParserFunction()}} from the parent frame. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::FYI: another little known fact is that Scribunto has translations of {{code|#invoke}} so such can actually be accessed via alias keywords on for example a Korean or Russian Mediawiki, etc.; that makes it pain to search for all such invocations of a module but luckily few people know and use aliases. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 21:29, 10 July 2025 (UTC) :::: Hi [[User:Uzume|Uzume]]. Thank you for the sandbox module. I think I understand now. As for <code>msg</code>, you can check yourself: ::::* <syntaxhighlight lang="wikitext" inline>{{if|eq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{if|eq|a|a|x|y}} ::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{#invoke:params|new|concat_and_call|if|eq|a|a|x|y}} ::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{#invoke:params|new|concat_and_magic|msg|if|eq|a|a|x|y}} ::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}}</syntaxhighlight> ::::*: ↳ {{#invoke:params|new|concat_and_magic|#ifeq|a|a|x|y}} :::: You can also experiment with a new module and <code>:callParserFunction()</code> to see if there is a problem in [[Module:Params]]. But there are no reasons to replace <code>:expandTemplate()</code>. As for replacing <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code>, we need to see if in these language in which they use a local translation of <code>#invoke</code> the English <code>#invoke</code> still works (I think it should). Otherwise this module will become a nightmare to maintain. If the English <code>#invoke</code> does not work we should leave the module as it is and simply warn that in case of > 99 parameters or in case of modules that check how they have been invoked, people should use the local version of <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code>. I wonder what the performance difference is between using <code>:callParserFunction()</code> + <code>#invoke</code> and <code>:newChild()</code>. I will run some tests. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 15:34, 11 July 2025 (UTC) :::::@[[User:Grufo|Grufo]]: I think {{code|msg}} not being recognized as a parser function is likely a bug. The question is where the bug is: your module, the Scribunto extension, MediaWiki proper or some other weird place (i.e., unforeseen interaction somewhere). As shown below, the first argument can cause this error in some cases: :::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}</syntaxhighlight> :::::*: ↳ {{#invoke:params|new|concat_and_magic|canonicalurl|:ja}} :::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}</syntaxhighlight> :::::*: ↳ {{#invoke:params|new|concat_and_magic|canonicalurl|::ja}} :::::This definitely needs more investigation. I might have to look into that. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC) :::::Yes, Scribunto ensures {{code|#invoke}} always works even when there are localized alias names. This is in a fashion similar to MediaWiki base namespace names, e.g., Chinese Wikipedia might have another name for <code>{{ns:10}}</code> but that name always works everywhere (even here we have a different base name for the {{code|Project}} namespace but {{code|Project}} still works; i.e. <syntaxhighlight lang="wikitext" inline>{{ns:Project}}</syntaxhighlight> yields <code>{{ns:Project}}</code> and <syntaxhighlight lang="wikitext" inline>{{ns:Image}}</syntaxhighlight> yields <code>{{ns:Image}}</code>, etc.) they just act like a redirect alias to the localized name. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC) :::::FYI: Another little known fact is that {{em|all}} Scribunto module pages are in content language English (I am not sure that is really the right choice but I am not planning to fight it anytime soon) even on Mediawiki instances where English is really used nowhere else. As an example, try going to [[zh:Special:EditPage/Module:Var#mw-scribunto-console]] and type into the debug console: <syntaxhighlight lang="lua" inline>mw.log(mw.title.getCurrentTitle().pageLang.code)</syntaxhighlight>. You will get: {{code|en}}. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:52, 11 July 2025 (UTC) :::::: {{Re|Uzume}} Now I don't have the time to create a test module and check <code>:callParserFunction()</code> with <code>msg</code>. However writing <code>::ja</code> as argument seems to make the <code>canonicalurl</code> parser function invisible even when called directly (see third example): ::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl:ja}}</syntaxhighlight>; the latter yields ::::::#: ↳ {{canonicalurl:ja}} ::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|:ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl::ja}}</syntaxhighlight>; the latter yields ::::::#: ↳ {{canonicalurl::ja}} ::::::# <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|canonicalurl|::ja}}</syntaxhighlight> corresponds to <syntaxhighlight lang="wikitext" inline>{{canonicalurl:::ja}}</syntaxhighlight>; the latter yields ::::::#: ↳ [[:Template:Canonicalurl:::ja]] :::::: As for moving from <code>:newChild()</code> to <code>:callParserFunction()</code> + <code>#invoke</code>, as soon as I have a moment I will update [[Module:Params/sandbox]] and run a few tests. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:13, 11 July 2025 (UTC) :::::::@[[User:Grufo|Grufo]]: Yes, that is interesting how the parser decides that syntax could not be a parser function call (because the argument is not a legal pagename?) and then falls back to parsing it as a template invocation of that pagename. The error from {{code|frame:callParserFunction()}} is definitely coming from [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/LuaEngine.php#L807-L810 the Scribunto PHP code] but the point you bring up may in fact be related (see below). As memory serves, when the parser is parsing normal wikitext, it handles parser function calls by parsing out the name and the chunk of wikitext to the end of the call (i.e., <code>{{))}}</code>) only separating them out by <code>{{!}}</code> and then calling the parser function code itself giving it a chance to "claim" the provided wikitext arguments (which are {{em|not}} yet fully parsed) and the parser function then decides how to parse such (some use the frame parser but many do not, e.g., {{code|#switch}} depends on the order/positioning of its arguments so it cannot use the frame parser and this is also why Scribunto {{code|#invoke}} can never perfectly emulate it) but I believe the parser function can also return to the parser stating it does not claim the provided wikitext arguments and in such a case the parser must march on assuming that it was not in fact a call to that parser function. I believe that is what is happening in your example above. Maybe something similar is happening in the {{code|frame:callParserFunction()}} path. It would kind of make sense there would be no way to actually call the parser function with entirely pre-parsed arguments so that path perhaps reconstructs the pseudo-unparsed wikitext arguments from the provided arguments and passes it to the parser function just as it would during normal wikitext processing. Then if the parser function rejects it, the parser assumes it was not a parser function call and eventually Scribunto yields the error: {{error|function "{{var|function}}" was not found.}} since there is probably no way to differentiate this from someone trying to call a nonexistent parser function, meaning the "not found" in the error is deceptive and should probably say something more like {{error|failed to execute function "{{var|function}}".}} Maybe this is an issue with the way the pseudo-unparsed wikitext arguments are reconstructed that causes {{code|msg}}, {{code|msgnw}} and {{code|raw}} to always reject the call. There may also be something special about {{code|msg}} and friends as in the history of wikitext parsing it was the {{em|first}}—even before normal template syntax existed and template syntax was implemented as a simplification. I wonder if {{strong|parsoid}} has the same issue. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 20:17, 11 July 2025 (UTC) :::::::: @[[User:Uzume|Uzume]]: I agree that the error is deceptive. Let me know if you find out more. In the meanwhile I have updated [[Module:Params/sandbox]] with a new version that replaces <code>:newChild()</code> with <code>:callParserFunction()</code> + <code>#invoke</code>. It will still require extensive testing. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 05:17, 12 July 2025 (UTC) :::::::::@[[User:Grufo|Grufo]]: Okay, yes, I have determined parser functions themselves {{em|can}} and apparently sometimes {{em|do}} return the PHP value <syntaxhighlight lang=php inline>[ 'found' => false ]</syntaxhighlight> which will ultimately lead to that error, however, I think the issue with {{code|msg}}, {{code|msgnw}} and {{code|raw}} is different. I notice they do not show up on [[Special:Version#mw-version-parser-function-hooks]]. They are clearly magic words that take parameters but it looks like they might be handled special by the parser and technically are not parser functions or something which would explain why they cannot be reached by [https://github.com/wikimedia/mediawiki/blob/a5b5777ae4ec274a4ee347c5716d9a4b8180b1fb/includes/parser/Parser.php#L3460 <syntaxhighlight lang=php inline>MediaWiki\Parser\Parser()->callParserFunction()</syntaxhighlight>] (and it {{em|does}} rebuild the arguments for parser function calls in a sort of pseudo-unparsed fashion and the first argument has some special handling) which is used by [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/LuaEngine.php#L775 <syntaxhighlight lang=php inline>MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaEngine()->callParserFunction()</syntaxhighlight>] and ultimately via its Lua library interface. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC) ::::::::::@[[User:Grufo|Grufo]]: Okay, I read through the main parser again and in {{code|braceSubstitution()}} it clearly shows that {{code|msg}}, {{code|msgnw}} and {{code|raw}} are {{strong|NOT}} parser functions. It looks for and handles these in this order: ::::::::::#{{code|subst}} and {{code|safesubst}} prefixes ::::::::::#variables (which are sort of like argument-less parser functions) ::::::::::#{{code|msg}}, {{code|msgnw}} and {{code|raw}} prefixes ::::::::::#parser functions by actually calling the same interface Scribunto calls: {{code|callParserFunction}} ::::::::::#page transclusions, i.e, template syntax ::::::::::#special transclusions from "special pages" ::::::::::Then that function finishes up with some other processing like loop checking and HTML DOM updates, etc. ::::::::::The {{code|msg}}, {{code|msgnw}} and {{code|raw}} prefixes "work" because they are mostly just deleted and do nothing but the code continues on and eventually finds the template transclusion so it appears to do that. {{code|msgnw}} and {{code|raw}} do set some flags but the same flags can sometimes also be set by some of the parser functions which can be seen in the handling at the return of the parser function call. This means some weird syntax is allowed, e.g., <syntaxhighlight lang=wikitext inline>{{msg:canonicalurl:ja}}</syntaxhighlight> and <syntaxhighlight lang=wikitext inline>{{canonicalurl:ja}}</syntaxhighlight> both yield {{msg:canonicalurl:ja}} but one can also do <syntaxhighlight lang=wikitext inline>{{msgnw:canonicalurl:ja}}</syntaxhighlight> which yields {{msgnw:canonicalurl:ja}} (notice no link; this is because "nw" means nowiki but not as in the strip-marker generating tag but as in HTML entity escaping). It also means that this type of functionality is {{em|not}} directly available from Scribunto Lua (at least not without {{code|frame:preprocess()}}). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:03, 12 July 2025 (UTC) :::::::::Here are some more examples of core parser functions (I do not plan to go searching through every extension) that themselves return the deceptive "not found": :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|int|help}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|int|help}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|int|}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|int|}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#interwikilink|d}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|#interwikilink|d}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|#interwikilink|x}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|#interwikilink|x}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|project}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|project}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|xyzzy}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|xyzzy}} :::::::::* <syntaxhighlight lang="wikitext" inline>{{#invoke:params|new|concat_and_magic|ns|829xyzzy}}</syntaxhighlight> :::::::::*: ↳ {{#invoke:params|new|concat_and_magic|ns|829xyzzy}} :::::::::Oddly this one never returns the error so long as it is passed a value that starts with an integer value other than {{code|0}} (and it also takes exactly {{code|0}} too) even when such an integer value corresponds to no such namespace, e.g., <syntaxhighlight lang="wikitext" inline>{{ns:-500xyzzy}}</syntaxhighlight> parses as a valid parser function call. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC) :::::::::One thing about parser functions "failing" that bothers me is that there does not seem to be anything that specifies to the parser this type of dependency. One of the key tenants of parsoid is to be able to (re)parse parts of a page potentially out of order doing the right thing based upon a dependency chain (sort of like a software build tool like [[make (software)|make]]). A key example is the new {{code|#interwikilink}} which fails when it is provided an invalid interwiki prefix but that is dependent on MediaWiki configuration. This means that I could place some wikitext somewhere that calls {{code|#interwikilink}} and fails but at some future point it might suddenly succeed. Suppose I lobby for some new interwiki prefix at [[m:Talk:Interwiki map]] and it succeeds and soon afterwards is deployed. Does this mean all MediaWiki wikis at WMF (and whatever else uses those maps) needs to reparse {{em|all}} pages everywhere (Commons literally has millions) because they {{em|might}} contain wikitext that will now suddenly render differently (properly)? If this dependency was somehow stored then the parser would know which pages (and/or page parts) to reparse (and whatever depends on them in turn, etc.). But nowhere is it documented, let alone specified, when and how a parser function will choose to parse something (or lack thereof; i.e., fail and not parse something). So the main parser cannot know when such parser functions change their mind. Maybe I am overthinking things because there are clearly timestamp type of magic words that obviously change their minds on a regular basis and things are just kept "fresh" at a regular cadence. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 09:13, 12 July 2025 (UTC) :::::::::: <span class="anchor" id="speed-test-1"></span>@[[User:Uzume|Uzume]]: I think you should bring the part of this discussion that concerns parser functions to [[:mw:Extension talk:ParserFunctions]]. Going back to the original point, here is the bad news about my latest experiments. If I write the following wikitext (which uses <code>:newChild()</code>) 12 times in a page and display the preview, I get an average “Lua time usage” of &lt; 0.1 seconds: :::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params|new| imposing|99|| filling_the_gaps| mapping_by_replacing||true|1|strict| mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false| for_each|[$#::$@]}}</syntaxhighlight> :::::::::: On the other hand, if I write the following wikitext (which uses <code>:callParserFunction()</code> + <code>#invoke</code>) 12 times in a page and display the preview, I get an average “Lua time usage” of 0.7 seconds: :::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params/sandbox|new| imposing|99|| filling_the_gaps| mapping_by_replacing||true|1|strict| mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false| for_each|[$#::$@]}}</syntaxhighlight> :::::::::: Therefore now I am no longer so sure we should drop <code>:newChild()</code>… --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:34, 12 July 2025 (UTC) :::::::::::@[[User:Grufo|Grufo]]: I do not think [[mw:Extension talk:ParserFunctions]] is appropriate at all. That would be for discussion just about that extension including the parser functions from that extension, e.g., {{code|#expr}}, {{code|#if}}, {{code|#ifeq}}, {{code|#titleparts}}, etc. but not about parser functions in general nor about core parser functions. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC) :::::::::::As for your performance data, that is very interesting but remember, though {{#invoke}} does have nontrivial overhead (and there are some Phabricator issue tickets about such things) it also means your client code can run loops more than 99 times so long as they do not run out of resources {{em|and}} that they will run properly even with modules that detect how they are loaded and provide a different package interface when loaded via {{code|require}} than with {{code|#invoke}} (it is also trivial to detect {{code|mw.loadData}} but that is sort of a moot point from your perspective as it can only return static data that cannot be executed). So yes, your {{code|newChild}} hack is somewhat faster but it is also buggy and your clients will half to take that into account. I am assuming ([[Module:Params]] is long with lots of indirection; I did not read through all of it) you are calling both {{code|newChild}} and {{code|callParserFunction}} off the parent frame to keep that in tact for the target module. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC) :::::::::::[[Module:Params]] claims it is not designed to be used from other modules via {{code|require}}. To that end it could detect how it is loaded and provided a different interface when loaded via {{code|require}} keeping people from accessing it in such a manner (or fixing it so it does provide useful functionality under such conditions). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:39, 12 July 2025 (UTC) {{outdent|:::::::::::}} @[[User:Uzume|Uzume]]: Uh right. With this module being invoked via wikitext, the information that the second module (e.g. [[Module:String]] in my examples) has not been called via <code>require()</code> should be propagated and inherited, right (even if we actually call that via <code>require()</code>)? As for <code>:newChild()</code>, I was wondering if a solution like <code>frameTools.makePseudoFrame()</code> found [https://dev.fandom.com/wiki/Global_Lua_Modules/FrameTools here] could solve everything. The 99 parameter limit comes from a limitation in the number of child frames that can be created, however we don't really need so many child frames, since they are all identical except for one or two parameters. The ideal solution would be that they make the <code>frame.args</code> metatable editable upstream, so that we stick to one. Lacking that, I was wondering if we could use the “pseudo frame” object mentioned in that wiki. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:32, 13 July 2025 (UTC) :@[[User:Grufo|Grufo]]: You mean will the [[Fandom (website)|Fandom]] {{code|makePseudoFrame}} from [[CentralWikia:dev:Module:FrameTools|Module:FrameTools]] (with the documentation you mentioned at [[CentralWikia:dev:Global Lua Modules/FrameTools|Global Lua Modules/FrameTools]]) solve your problems? Yes...no and maybe. I am not exactly sure without testing but I think the concept is mostly sound. That said, it {{em|definitely}} introduces more caveats. :There is no guaranteed your target module will even use the {{code|frame}} argument it is provided in the call as it can always fetch the real frame from {{code|mw.getCurrentFrame()}} and you are almost guaranteed that it will use such during package initialization if it wants access to the frame at all, because there is no other method for access (at that point the {{code|frame}} argument is not available as it is before the target function has even been indexed much less called because it is the initialization block that returns the package table the target function is indexed from). One common idiom I have seen here is a package function that uses a construction like {{code|lang=lua|1=if frame == mw.getCurrentFrame() then}} allowing the package function to potentially work under {{code|#invoke}} {{em|or}} {{code|require}} (I do not consider this practice as good as the example module I gave you but it does something {{em|somewhat}} similar in attempting to handle both situtations). Currently, a search of all EN Wikipedia Scribunto module code for {{code|getCurrentFrame}} {{sl|all: contentmodel:Scribunto insource:/getCurrentFrame/|yields 620 hits}}. Of those, I found this programing idiom at:{{div col|content={{ulist |[[Module:Archive list alpha#L-329--L-337]] |[[Module:Archive list#L-313--L-321]] |[[Module:Armenian#L-10--L-18]] |[[Module:BaseConvert#L-89--L-93]] |[[Module:BellezzasoloUserPageModule#L-139--L-143]] |[[Module:British regnal year#L-12--L-20]] |[[Module:Csdcheck#L-24--L-36]] |[[Module:Fixme#L-71--L-79]] |[[Module:Japanese calendar#L-214--L-222]] |[[Module:PageLinks#L-274--L-282]] |[[Module:QuidAppearances#L-65--L-69]] |[[Module:Random#L-298--L-304]] |[[Module:Roman#L-98--L-106]] |[[Module:Sandbox/Ahecht/interwiki#L-80--L-88]] |[[Module:Sandbox/AlphaZeta/test4#L-25--L-29]] |[[Module:Sandbox/Frostly#L-237--L-245]] |[[Module:Sandbox/Hawkeye7#L-177--L-185]] |[[Module:Sandbox/Mlkj#L-313--L-321]] |[[Module:Sandbox/Retro#L-26]] |[[Module:Sandbox/Szqecs/Adjacent_stations#L-164--L-168]] |[[Module:Sandbox/Toohool#L-22--L-34]] |[[Module:Track gauge#L-11--L-19]] }}}} :These all use {{code|getCurrentFrame}} and soon compare it to something with {{code|1===}} (oh, and be glad I did not spam you with all the {{code|/sandbox}} copies too). All of these will {{em|already}} fail with your {{code|newChild}} hack (unless you call {{code|callParserFunction('#invoke', ...)}} off the {{code|newChild}} frame but that sort of defeats your purpose for using it to begin with) because in Lua comparing two tables always fails unless they are the same table reference (i.e., {{code|1===}} does not do a "deep compare" to compare the table contents so it is only true if they are in fact the exact same table not a copy). And there maybe other modules that do such as well but hold the {{code|getCurrentFrame}} value and compare it in some other fashion or compare it at some later time, etc. I only looked briefly at the 620 search hit results. I did not look directly at the module code from all 620 hits. Incidentally, I also looked for comparison via {{code|1=~=}} but I could not find a single such usage which I find a bit odd as I would probably prefer that myself but apparently that is not popular. I almost never depend on the provided frame argument as it is not really reliable and {{code|getCurrentFrame}} is (although I suppose someone {{em|could}} attempt to [[monkey patch]] the {{code|getCurrentFrame}} field of the {{code|mw}} package table/global). :Scribunto {{code|newChild}} actually calls into the PHP code to create a new [[mw:Manual:PPFrame.php|PPFrame]] object (notice its own PHP {{code|newChild}} method) that the MediaWiki parser and extensions, etc. can all use. Fandom {{code|makePseudoFrame}} does not appear to do this but just creates a fake one in Lua by copying fields from another Lua frame table. To that end, it is worse than {{code|newChild}} but from your perspective, I would say it is perhaps considerably better. Consider this: {{code|makePseudoFrame}} is probably no worse than {{code|newChild}} with regard to using it and {{code|require}} to fake a {{code|#invoke}}. Both have same caveat of not being the frame of an actual {{code|#invoke}}. However {{code|makePseudoFrame}} has the additional caveat of introducing potential issues for the target module if it uses the provided pseudo-frame to call back into MediaWiki (e.g., where do you think the parser will get arguments for parameter references like {{param|1}} in a {{code|preprocess}} call?). If you use {{code|newChild}} you are trapping those in the new PPFrame (which PHP does not let you change and this is why Lua does not let you change them either; this is also the source of the frame count limitation) so those references work (even if the target module {{code|could}} detect is is not actually being be called via {{code|#invoke}}). This is why I say {{code|makePseudoFrame}} introduces more potential caveats. On the other hand, it will likely be considerably faster as it does not call into PHP and it will not have the PHP frame count limitation (and you probably can write into its arguments although since it is a purely Lua table and its overhead is small you can probably just ensure it gets deleted and recreate it cheaply). My take on it is that if you are considering keeping your {{code|require}} based {{code|#invoke}} emulation, you would likely be better to switch from {{code|newChild}} to {{code|makePseudoFrame}}, however, I would encourage you to pursue a proper {{code|#invoke}} solution over the {{code|require}} based emulation. And at the very least you should rename and very clearly document that those functions in {{mlx|Params}} are {{code|#invoke}} emulations that have lower overhead but only work sometimes when the target module does not do much discrimination on how it is actually loaded (e.g., initialization block {{code|...}}), its provided frame arguments (e.g., comparing it to {{code|getCurrentFrame}}) or calling back into PHP in certain ways (e.g., {{code|preprocess}} with {{code|makePseudoFrame}}). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:12, 13 July 2025 (UTC) :: Thank you for your incredibly detailed answer, [[User:Uzume|Uzume]]. What I don't understand is this: how is possible that if I want to call a module via <code>require()</code> + <code>:newChild()</code> I hit the &lt; 100 parameters limitation, whereas <code>#invoke</code> is able to bypass it? How does it do it? Shouldn't it suffer from the same PHP limitation too? I was thinking that maybe the best solution at the moment is to leave everything as it is and write about it in the documentation. I think so because this is the solution that gives the maximum freedom of choice. Currently if one wants to favour performance can use, for instance <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_invoking]]&#124;...</code>, whereas if one wants to have the possibility of having 1000 parameters (at the cost of a slower solution) can use <code>...&#124;[[Module:Params#mapping_by_invoking|mapping_by_magic]]&#124;#invoke&#124;...</code> --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 17:35, 13 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: I took a brief look at your module's usage of {{code|newChild}} as well as {{code|makePseudoFrame}} (which can be directly compared with Scribunto's own <code>[https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/e93d49ff0570930922a25ca515068c89397ae5ae/includes/Engines/LuaCommon/lualib/mw.lua#L153-L456 newFrame]</code>). First, you should really consolidate your {{code|#invoke}} code whether it is an emulation or not (and while you're at it also encapsulate {{code|expandTemplate}} and {{code|callParserFunction}}; FYI: I do not like your usage of the word "magic" as it only supports parser functions not all types of magic words so you should really consider renaming those too). There is no reason to have five copies scattered around needing different maintenance. :::How about a single invoker that takes an emulation parameter and either does a real invoke or emulates one? Then the caller can choose, and if you really get daring, the parameter can be more than a boolean specifying the emulation type, i.e., to what lengths should the emulation employ. There are some things I am not too thrilled with about {{code|makePseudoFrame}} (and I think I found a minor bug in it too). If you are serious about trying to maintain a {{code|#invoke}} emulator, I have some ideas on how to build a better mousetrap. :::I am not sure if there is a good way to fake the environment for the module initialization block (e.g., {{code|...}}, etc.) as hacking that would probably have security implications and as such is likely locked down well but remember that it runs at a very different time to the execution of the package functions which get executed later either by Scribunto directly (i.e, via {{code|#invoke}}) or by Lua calls from module code, typically needing a {{code|require}} to get access to the package. If you look at {{code|newFrame}}, Scribunto's own frame object generation code, you might notice that they are generic tables without a metatable. Sure, the {{code|args}} field is another subtable and it is {{em|definitely}} metatabled but the main frame objects do not seem to be (of course someone might go and change things at some later date but at the moment that is true). To that end, it gave me an idea to help you with your emulation and potentiality alleviate your 99 frame limit whoas. Why not use real {{code|newChild}} but do it later only upon demand? Your code seems to proactively create a {{code|newChild}} at every emulated {{code|#invoke}}. If you instead, created a dummy table with a metatable and pass that in, you could wait until the target code actually tries to reference fields from the dummy frame and only {{em|then}} create the {{code|newChild}} upon demand and return values from there. This way if the target module never uses the dummy frame object, {{code|newChild}} is never actually called. You could also try and monkey patch the {{code|mw.getCurrentFrame}} to return the same dummy frame object fixing those situations I mentioned above. Of course if the target module does try to use its frame object, then you will be forced to call {{code|newChild}} and provide one so the number of iterations would be limited then. Since most modules at least attempt to use the frame {{code|args}}, you will likely want to handle that yourself avoiding the {{code|newChild}} call. You will likely want to handle {{code|getTitle}} and {{code|getParent}} (for its own {{code|args}}) too but in other cases you could punt to {{code|newChild}} upon demand. The code would likely be pretty tricky but it should work fairly well (except for possible initialization block issues referenced earlier). Just some ideas. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 18:30, 13 July 2025 (UTC) :::: Thank you again, [[User:Uzume|Uzume]]. As for the nomenclature, I might agree that “magic” is a bit creative, but it has the advantage of being short. Any other solution was lengthier. But I am definitely open to suggestions, as long as they are coherent with the rest of the names. As for “consolidate my <code>#invoke</code> code” and “encapsulate <code>expandTemplate</code> and <code>callParserFunction</code>”, I am not totally sure I understood what you mean. As for creating a metatable and passing that, there is no way that the target module does not access its <code>frame.args</code> metatable in functions like <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code>, so at least that will have to be a “fake” parameter table. I was thinking that I could create a single <code>:newChild()</code>, create a metatable, redirect all its fields except <code>frame.args</code> to that single child frame, and use a normal (always changing) table for <code>frame.args</code>. How does this sound? You might have just given me an idea to experiment with. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 18:58, 13 July 2025 (UTC) :::::@[[User:Grufo|Grufo]]: By encapsulate I mean make a function or something so there is only one copy of the code to maintain and have everything that needs to accomplish that feat use that function (or class object, etc.). Your idea sounds like an interesting starting point but I do think you are going to run into many weird corner cases and you need to be {{em|very}} meticulous and methodical with your design and implementation. And I question the need for {{code|newChild}} if you are not planning to capture the args in an actual parser frame (because you keep changing them without a {{code|newChild}} for every change). What you are suggesting is very much like the Fandom {{code|makePseudoFrame}} (which does not bother with {{code|newChild}} {{em|because}} it does not capture the args in an actual parser frame). Of course doing that presents issues if the target module tries to call back into parser as the parser will then not know about those uncaptured args. Instead of "magic" why not just "pf" or "parserfunc" or some such. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:12, 13 July 2025 (UTC) :::::: @[[User:Uzume|Uzume]]: <code>:newChild()</code> would be needed because the callback module might want to access other fields of the frame object (e.g. <code>:callParserFunction()</code>, or <code>:getParent()</code>, and in this way it will have the entire suite of fields ready. These remain constant for the entire duration of this module's invocation, so it makes sense that they always refer to a single child frame. The only thing that the callback modules can see changing is their <code>frame.args</code> field. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:20, 13 July 2025 (UTC) :::::::@[[User:Grufo|Grufo]]: Even if they remain constant, why bother with {{code|newChild}} if you can get them from your own frame? Well the only thing they will see is the changing {{code|frame.arg}} {{strong|if and only if}} that is all they look at. You mentioned the target module might want other fields. What if it wanted say {{code|preprocess}}? The parser does not know about your changed uncaptured args so the {{code|preprocess}} has the possibility of rending incorrectly (e.g., parsing {{param|1}}, etc.) The point is, either capture the args with a real {{code|#invoke}} or {{code|newChild}} {{em|or}} don't and then there is no real need for {{code|newChild}}. Besides the functions themselves, a frame is really only a page name and a set of args. Sure you might be able to capture the title but if you are tweaking the args all the time, it would be very little work to handle the title yourself too. If you handle both, I do not see the point. What does even a single {{code|newChild}} buy you. I say very little under those circumstances. Of course it it is only one call so feel free to explore, but I really do not see the need. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:46, 13 July 2025 (UTC) :::::::: @[[User:Uzume|Uzume]]: There are many little reasons why <code>:newChild()</code> is necessary. For instance in the callback module <code>frame.args</code> should return the parameters passed to the callback module itself, whereas <code>frame:getParent().args</code> should always return the calling template's parameters (I mean the parameters passed to the template that invoked [[Module:Params]]); or <code>frame:getTitle()</code> should return, for instance <code>Module:String</code>, whereas <code>frame:getParent():getTitle()</code> should always return the calling template's name, and so on. As for <code>frame:preprocess()</code>, you are possibly making a valid point (I should test it). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 23:54, 13 July 2025 (UTC) :::::::::@[[User:Grufo|Grufo]]: But you can just pass back your module's parent frame for {{code|getParent}} and you already know the target module's full pagename as you need that to call {{code|require}} so you can easily implement {{code|getTitle}}. Anyway, I have not tested this at all however, I made a first try at creating an {{code|invoke}} function in [[Module:Sandbox/Grufo]]. I am not sure how robust it is but it should spoof {{code|args}}, {{code|getParent}} and {{code|getTitle}} while also monkey patching {{code|getCurrentFrame}} and never creating any frames until the target module attempts to access one of the other fields. Then it calls {{code|newChild}} and updates all the fields to stop spoofing things but just passing calls to the on demand created child frame. This will still have a 100 frame limitation if the target module uses those fields, but if it sticks to just those three that I have spoofed, it should never hit any such limit. It might be possible to spoof some of the other fields but they do not seem to be in much demand besides the ones that probably require calling back into the parser anyway. It also can do nothing about load detection in the target modules initialization block. It certainly has some key caveats but I think this should work for the vast majority of cases and be a little lighter on resources than doing many actual {{code|#invoke}} calls. Let me know what you think and if you try it out, etc. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 01:17, 14 July 2025 (UTC) :::::::::: Thank you for your code, [[User:Uzume|Uzume]]. I have not tested it yet, but it seems to me that on demand (i.e. delayed) it creates a child frame for each callback, am I wrong?. This means that with functions like <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> it will hit the &lt; 100 limitation for sure, because these callbacks can never ignore the <code>frame.args</code> metatable. P.S. I started playing around with my solution, but so far I did not find a way to make the methods of the pseudo frame object work (none of them). Only the fields work. This happens because of [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 this restriction]. So I will have to find a way somehow to bypass it. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 04:04, 14 July 2025 (UTC) :::::::::::@[[User:Grufo|Grufo]]: No, that is not how it designed to work. It creates the {{code|frameSpoof}} and passes that instead. It is filled with fields that are punting stub functions that will call {{code|newChild}} and then rewrite the stub functions to other stub functions that will use the created {{code|newChild}}. This way if the target module does access one of the unspoofed fields, {{code|newChild}} will be called from inside the target module by one of the punting stub functions but only once. But before I am done creating the {{code|frameSpoof}}, I overwrite the fields I want to spoof including {{code|args}}, {{code|getParent}} and {{code|getTitle}}. So target modules that only use those three fields will use those spoofed values and {{strong|never}} have {{code|newChild}} called. In fact, technically the target module is calling {{code|newChild}} when it calls one of the punting stub fields that are not spoofed. This is why the {{code|newChild}} is delayed. It is also why target modules that do not touch those other punting fields will never actually call {{code|newChild}}. We cannot control what the target module will do but we {{em|can}} respond to what it does do. So I wrote it inside-out which makes the code a little weird and maybe hard to follow. Once {{code|frameSpoof}} is completely constructed with its one-time punting stubs and three spoofed fields, I monkey patch {{code|getCurrentFrame}} to return my {{code|frameSpoof}} and then call the target module function and then immediately unpatch it before returning the value from the call to the target module function. Remember, you are not just spoofing the target module function. You are spoofing that and {{strong|everything}} it calls including other modules it loads and calls via {{code|require}}, etc. Your module's main use cases make it lean towards being used with other modules that have functions with fairly simple functionality (otherwise why call them repeatedly?). If those target module functions are simple enough to not trigger one of the {{code|newChild}} stubs in {{code|frameSpoof}} (i.e, one of the punt stubs vs. the spoof fields), they never need do any punting to {{code|newChild}} at all. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 06:46, 14 July 2025 (UTC) :::::::::::: @[[User:Uzume|Uzume]]: I am amazed. But I have to admit that you lost me there. I will probably have to just study your code. But just as a quick understanding, if I were to implement <code>[[Module:Params#mapping_by_invoking|mapping_by_invoking]]</code> using your solution, and then I were to launch the following code (which calls {{mfl|string|replace}} 101 times), :::::::::::: <syntaxhighlight lang="wikitext">{{#invoke:params|new| imposing|101|| filling_the_gaps| mapping_by_replacing||true|1|strict| mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false| for_each|[$#::$@]}}</syntaxhighlight> :::::::::::: would I hit the &lt; 100 parameters limitation? --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:48, 14 July 2025 (UTC) :::::::::::::@[[User:Grufo|Grufo]]: Based upon my understanding and having studied [[Module:String]] (so I know it hardly touches its frame for anything other than {{code|args}}), I believe you should not hit such a limit (although you might hit others I am not sure). But of course such things need testing. I did some basic testing to make sure it appears to work in general. But I certainly did not test it to that extent. Also it {{em|really}} needs more input validation, etc. For example, right now, I could pass in some nasty things to {{code|modargs}} that are not strings, etc. But assuming one does not do anything crazy, I believe it should handle your situations fairly well. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:04, 14 July 2025 (UTC) :::::::::::::: @[[User:Uzume|Uzume]]: Thank you. Some personal commitments got in the way, and I won't be free until the beginning of August (so I will just do ordinary admin tasks on Latin Wikipedia for the next days). But I want to get to the bottom of this. In the meanwhile, if you find a solution that never hits the &lt; 100 limitation, please make a whistle. The ideal would be that we found a way to create a <code>:newChild</code> only once. But unfortunately, due to [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 this restriction] using a custom metatable instead of the original frame won't work. And honestly at the moment I am in lack of frash new ideas. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:55, 16 July 2025 (UTC) :::::::::::::::@[[User:Grufo|Grufo]]: Yes, I too noticed how the Lua frame object methods created by {{code|newFrame}} use their private {{code|checkSelf}} function to validate the passed in frame table {{code|self}}arguments preventing anyone from calling those functions without with passing in the exact table they were created for. This is probably why {{code|makePseudoFrame}} creates a bunch of stub functions like [[CentralWikia:dev:Module:FrameTools#L-76--L-84|this]] that punt/redirect calls to a passed in real frame object. It is also in part why I do something similar with regard to creating punting stub functions as well as replicate the {{code|checkSelf}} style code to propagate errors. That said, even without the {{code|checkSelf}} restrictions, passing in different frame objects probably would not work anyway due to the way they {{code|newFrame}} creates a [[closure (computer programming)|lexical closure]] for each frame method and each depend on their upvalues. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 07:32, 17 July 2025 (UTC) :::::::::::::::@[[User:Grufo|Grufo]] You recently mentioned Postel's [[robustness principle]], in an entirely different context, but to that end I thought I would mention some things. I have improved my {{code|invoke}} emulation code at [[Module:Sandbox/Grufo]] including better monkey patching of {{code|mw.getCurrentFrame}} to allow it to be seen by the target module initialization block (i.e., {{code|require}}), completely saving and restoring {{code|package.loaded}} so it appears {{code|require}} was never called, and perhaps most importantly sanitizing the given {{code|modargs}}. Remember {{code|#invoke}} and {{code|newChild}} will provide a target module with {{code|frame.args}} that have stringent requirements. The passed in {{code|modargs}} are spoofed to the target module without going through such things so they need to emulate them closely or the target might get weird things it is not expecting, e.g., the target module might check {{code|args[1]}} but the given {{code|modargs}} might have a value like {{code|args['1']}} which would not be seen as the same (conversely {{code|modargs}} might have {{code|args[1.2]}}). BTW, I tried creating a proof of concept at [[Module:Params/sandbox]] by loading my {{code|invoke}} via {{code|require[[Module:Sandbox/Grufo]]}} and I ran into some major problems. [[Module:Params]] has {{strong|serious}} bugs. I wrote [[Module:Sandbox/Grufo]] to use [[mw:LUAREF#strict|strict]] to avoid inadvertent global reference bugs but it exposes them in [[Module:Params]]. You should really at least test with {{code|strict}} as you never know what your target modules may or may not call. If they are buggy and do not use it, you will break them if you use it, however, if they use it and your code is buggy they will break your code. So even if you chose to not use it in [[Module:Params]] itself, you should really consider testing with it turned on early to expose as many of your bugs as possible so that you won't have such things and the target module cannot break you by exposing such with {{code|strict}}, etc. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 04:57, 21 July 2025 (UTC) :::::::::::::::: @[[User:Uzume|Uzume]]: Thank you a lot for helping with this and other modules. You will have to wait a few more days for me to have a look at [[Module:Params/sandbox]]. In the meanwhile I added the <code>strict</code> directive to [[Module:Params]], but [[Special:Diff/1297865432/1302040393|these]] were all the bugs I could find. Please let me know if you see any other bug! --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 01:16, 23 July 2025 (UTC) :::::::::::::::::@[[User:Grufo|Grufo]]: That is great. Thank you for fixing your issues related to [[mw:LUAREF#strict|strict]]. I was having problems trying to figure out what were the right fixes for those issues. I did find one more bug: [[Module:Params#L-1910]] {{code|fname}} should be {{code|mname}}. But this is related to your {{code|#invoke}} emulation paths so necessarily it will get fixed when converting to my own {{code|#invoke}} emulation code. To that end, I ported my sandbox proof of concept changes using my {{code|invoke}} emulation to the new active code (i.e., with your {{code|strict}} fixes) so now the proof of concept works and you can "look at" it when you get time. For example, this works: {{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|1025||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|1025||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|string|replace|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}} Cheers, —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 13:38, 23 July 2025 (UTC) :::::::::::::::::: @[[User:Uzume|Uzume]]: Good catch again! [[Special:Diff/1302041492/1302137674|Fixed]]! :-) --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 16:11, 23 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: That is an easy answer. MediaWiki owns the parser and the parser {{em|knows}} about the entire parse tree (well eventually it does anyway otherwise it cannot yield a completely parsed page and that is really the parser's main job). So even though you can use {{code|newChild}} to {{em|create}} a parser frame object, you do not really know when it is safe to {{em|destroy}} it and so Scribunto does not provide access to a frame destructor for frames. The parser {{em|does}} know so it merrily goes along creating and destroying them. If you call {{code|#invoke}} 200 times, so long as there is no dependency requiring the frames to continue to exist, MediaWiki destroys them (if you created a tree of recursions where each frame created more frames there would be dependencies and the frames would have to live longer). In this way, so long as nothing hits imposed resource limitations all is good. Since the main parser is unlikely to need {{strong|many}} frames at any single point in time, there is a limit imposed on them and you found it: 100. Since you cannot pass back unparsed text from Scribunto, I imagine the parser will quite quickly destroy all the frames you created with {{code|newChild}} upon exit of the {{code|#invoke}} to your module. This means you can batch such things, e.g., you could assume you can create 50 {{code|newChild}} frames without issue, then you could have some code that processes no more than 50 iterations and have your main code {{#invoke}} back into your own module where that entry point just does the 50 limit max and returns. Then your main code could get control again and keep doing this until the request is complete no more than 50 at a time. In fact the {{code|callParserFunction('#invoke', ...)}} route could be views as a "do only one iteration at a time" batch processor. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 19:00, 13 July 2025 (UTC) :::: Now it is all clear. Thank you! --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 19:04, 13 July 2025 (UTC) === Evaluation of <code>#invoke</code> emulation === @[[User:Uzume|Uzume]]: No deep code analysis yet, but if now I run [[#speed-test-1|these tests]] again your solution seems even faster than the original solution with <code>:newChild()</code>! Would you mind replacing [[Special:PermanentLink/1302784329#L-731|this line]] in [[Module:Params/sandbox]] with the actual <code>invoke()</code> function (i.e. no <code>require</code>)? P.S. I [[Special:Diff/1302113607/1302784329|double checked all the steps]], and that led me to restore <code>tostring(tmp)</code> at [[Special:PermanentLink/1302784329#L-1508|line 1508]]. That directive was born from [[Module talk:String#Protected edit request on 18 October 2024|this discussion]]. I did not check if your <code>invoke()</code> function already stringifies the returned value (in which case, it shouldn't, because as you can see, if it is compatible with a number we choose the number). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 12:48, 27 July 2025 (UTC) :@[[User:Grufo|Grufo]]: I do not mind pasting {{code|invoke}} directly into the sandbox, however, since you had some trouble understanding it, I instrumented it with long blocks of comments. I am not sure all of those are the best thing for directly pasting into the sandbox. Remember [[Module:Sandbox/Grufo]] is basically a sandbox itself and I made many improvements to it there. Yes, I noticed that extraneous {{code|tostring}} but my {{code|invoke}} emulates a {{code|#invoke}} so it does in fact always return a {{code|string}}. In fact there is a strange quirk there that I emulate as well. When the target module returns multiple values in its returned expression list, {{code|#invoke}} will treat them as a sequence and turns them all into strings and concatenates them. This means that if there are intervening {{code|nil}} values, they are seen as the end of the list. I emulate this by storing the return values into a table, iterating the table with {{code|ipairs}} putting each value through {{code|tostring}} and then calling [[mw:LUAREF#table.concat|table.concat]]. So [[Module:Sandbox/Grufo#L-186]] is meant to emulate [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/854851ee9bd1863585a0474a1b5b284d48fc5bad/includes/Engines/LuaCommon/lualib/mw.lua#L536 includes/Engines/LuaCommon/lualib/mw.lua line 536]. {{highlight|Anyway, the TLDR, part is that {{code|#invoke}} guarantees a string return value so my {{code|invoke}} emulates that and there is no need for a redundant {{code|tostring}}}}. Your {{code|#invoke}} emulation with a preemptive {{code|newChild}} did not do this right and that is why you previously needed the extra {{code|tostring}} (i.e., it should be considered a part of your {{code|#invoke}} emulation which I am replacing). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:00, 27 July 2025 (UTC) :@[[User:Grufo|Grufo]]: I pasted in a working copy of my {{code|invoke}} code so the sandbox no longer requires [[Module:Sandbox/Grufo]] and should work stand-alone again. However, if further development on that code is required, it will be a major pain to always keep them in synchronization. I did {{strong|not}} strip out the {{code|noemu}} {{em|real}} {{code|#invoke}} code (which can be easily tested by adding {{code|true}} to the end of the function call arguments) nor did I remove the overzealous and copious comments I put in there for your benefit. In production code, you might want to consider whether to keep such things so I cannot currently recommend you just accept the current sandbox {{em|as is}} but it should still be a good proof-of-concept for evaluation purposes as likely you will want to do something similar with some cleanup. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 15:58, 27 July 2025 (UTC) :: Thank you a lot, [[User:Uzume|Uzume]]. Got it. Don't worry about the comments, that is just a sandbox and they are very helpful there. We will do a cleanup for the final version. As for further developments, even if it is pasted inside a large module, it is still an independent function; it should still be easy to experiment separately with it in the future. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 16:13, 27 July 2025 (UTC) :::@[[User:Grufo|Grufo]]: As a reminder, {{code|newChild}} will not be called so long as the target module never uses anything from the {{code|frameSpoof}} that I actively spoof, i.e., {{code|getParent}}, {{code|getTitle}} or {{code|args}}. Here are some examples to demonstrate such:{{olist|1={{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}}|2={{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|100||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}}|3={{show|1=<syntaxhighlight lang="wikitext" inline>{{#invoke:params/sandbox|new|imposing|99||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}</syntaxhighlight>|2={{#invoke:params/sandbox|new|imposing|99||filling_the_gaps|mapping_by_replacing||true|1|strict|mapping_by_invoking|ustring|gsub|let|tag|nowiki|4|^.*$|Hello!|1|false|for_each|[$#::$@]}}}}}} In the first case, the target module never touches anything that is not spoofed so it works. The second fails because it adds {{para|tag|nowiki}} to the call and [[Module:Ustring]] wraps the output in the given tag by calling {{code|extensionTag}}—something that is not currently spoofed so it causes those to fallback to using {{code|newChild}}. The same is true in the third example, however it does not fail because it is just under the 100 frame limit. It should be noted that this falls back on a case-by-case basis. I cannot think of any really good examples off the top of my head but if you could say alternate the parameters to the target (i.e., along the lines of even vs. odd, etc.) then it would only call {{code|newChild}} in the situations where the target touched non-spoofed fields. In the odd—even case, one might effectively double the limit because it would only be using {{code|newChild}} half the time. You know [[Module:Params]] much better than I do so perhaps you can come up with some more interesting test cases. It also shows that we might be able avoid the above issue by extending {{code|frameSpoof}} by writing a spoof for {{code|extensionTag}}. I believe that might actually be possible. I know some extension tags do in fact call into the parser (e.g., {{tag|ref|o}} does this to render wikitext with its contents) but I {{em|believe}} they carry no parser context when they do (i.e., each is effective a new parser instance and doing things like {{tag|ref|content={{param|1}}}} is meaningless). I would have to research and test such. The same can be said for the other unspoofed fields (e.g., virtually nobody uses {{code|argumentPairs}} but I think it could be easily spoofed; I just did not bother to spend time on it). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 20:49, 27 July 2025 (UTC) ::::@[[User:Uzume|Uzume]]: I am still unsure whether including [your “frame spoof” code] in [[Module:Params]] [is a good idea] or not. Among the reasons there is that it is not perfect and it adds a lot of lines of code. The other thing that makes it look like a non-urgent fix is the fact that so far no template hit the “> 99 parameter limit” using [[Module:Params]], and when that were to happen, it will still be possible to write <code>{{mfl|params|mapping_by_magic|#invoke|...}}</code> instead of <code>{{mfl|params|mapping_by_invoking|...}}</code> – although I am pretty sure at that point this discussion will be re-opened. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:46, 29 September 2025 (UTC) :::::@[[User:Grufo|Grufo]]: I agree the code is not particularly small nor even easy to understand, however, I did try to make it as straightforward as possible. This is why I originally put it in [[Module:Sandbox/Grufo]] and had [[Module:Params/sandbox]] refer to it much like {{code|makePseudoFrame}} from [[CentralWikia:dev:Module:FrameTools|Module:FrameTools]]@[[Fandom (website)|Fandom]] might have been used. Remember, {{strong|you}} were the one that {{em|insisted}} on pasting that directly into [[Module:Params/sandbox]]. I personally believe you and [[Module:Params]] are hardly the only ones interested in an efficient <code>{{tlm|#invoke:}}</code> emulation. Towards that end, I believe it makes more sense to place that code within its own Scribunto module and have [[Module:Params]] reference it. You could spearhead a new stand-alone module, but that might be hard to argue due to its restricted current use case. So instead, I recommend creating a submodule like [[Module:Params/invoke]] and let it grow organically from there. Maybe one day someone else will be interested enough to make this into a stand-alone module that can be moved out from under [[Module:Params]]. At least that is my take on what should be done about it and I hope that answers your question as put to me. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 16:00, 29 September 2025 (UTC) :::::: Hi [[User:Uzume|Uzume]]. Creating a separate module is a minor issue. We can definitely do that, especially if other modules can benefit from your “frame spoof” solution – though, as long as [[Module:Params]] will be the only module that depends on it, that will be the only module able to spot (and suffer from) possible bugs. The question that bothers me however is: Can it be made perfect? Can it be made so that it can always deal with > 99 parameters? I like your solution because the code seems to run even faster than the current code. However it is not a minor change, and if currently nothing suffers from that problem I would be inclined to let us take more time to search for ideal solutions. And maybe invite other Lua developers to this discussion as well. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 21:49, 29 September 2025 (UTC) :::::::@[[User:Grufo|Grufo]]: Well, my "frame spoof" based emulation is not specifically limited by 99 frames as {{lang|la|per se}}. It is limited to ~99 frames where the target uses something beyond the basic "frame spoof" which then punts to using {{code|newChild}} and thus the limit. Everything has resource limits. It just depends on what resources are used. If the target does not use any frame fields beyond those provided by the basic "frame spoof", {{code|newChild}} is never used and so there is no 99 frame limit although I am sure there is some other resource limitation somewhere else eventually. If the target {{em|sometimes}} uses those fields beyond those provided by basic "frame spoof", then the emulation will only {{em|sometimes}} fallback to using {{code|newChild}}. Under such a situation, it would be limited to how many {{em|sometimes}} such were used. As an example, if you have a target that only uses {{code|newChild}} fields when some given argument is even (vs. odd), then the emulated frame limit would effectively be about twice the 99 {{code|newChild}} frame limit. If you know specifically which fields are falling back to {{code|newChild}}, it might be possible to improve the emulation to implement such in the "frame spoof", however, some will be extremely difficult to emulate correctly as they imply a call back into the parser which is hard to do without an actual parser frame. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 23:27, 29 September 2025 (UTC) :::::::One extremely crazy idea I just had would be to attempt to hang on to any output/side effects the target might create and then if the target uses something beyond the basic "frame spoof", instead of punting to {{code|newChild}}, backtrack/unwind the call to the target and re-execute using a real {{tlm|#invoke:}} off the parent frame. That should not have the ~99 frame limitation but would then cause the code to slow down (since as per your testing such is slower). That said, it might be hard to capture all the potential side effects of target execution in order to backtrack. I might think about that some more (obviously the main side effect of target execution is its output toward the page being rendered). —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 23:27, 29 September 2025 (UTC) :::::::: All clear. Please, feel free to run all the experiments you want here. You can create other sandbox submodules if you need. If only emulating <code>#invoke:</code> from modules were a more widespread necessity, we could also think about asking MediaWiki's backend developers to remove [https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/a091b46d65cdccbdbae6c52ec79c4df12859c3e2/includes/Engines/LuaCommon/lualib/mw.lua#L164-L171 all those ckecks] that forbid us to create a fully-functional pseudo-frame object. But here we are at the moment. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 00:10, 30 September 2025 (UTC) :::::::::@[[User:Grufo|Grufo]]: The checks are not really the main issue and in fact they are probably a good thing. The real problem is the cost of a true {{tlm|#invoke:}}. If the overhead was not so high there would be little reason to emulate it. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 10:07, 30 September 2025 (UTC) :::::::::: @[[User:Uzume|Uzume]]: As for the cost of a true <code>{{mwl|#invoke|}}</code>, I agree. Those checks however are what forbids us to create a simple Lua table that emulates the <code>frame</code> object (“pseudo-frame”) and call the native methods on such a table. If that were possible we would have a different discussion right now. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 10:59, 30 September 2025 (UTC) :::::::::::@[[User:Grufo|Grufo]]: Actually, no that is not true. It is true the checks stop such use but they are only a warning/error message. The real issue is the real parser frame that is passed back into the parser. The Lua functions are going to use the upvalue anyway. Checking the passed in {{code|self}} value matches the upvalue is probably a good thing ensuring calls are not made in error. Technically, those functions do not even need the passed in frame parameter (much less its argument value) to function properly. The check just ensures the caller isn't attempting something improper. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 11:13, 30 September 2025 (UTC) :::::::::::: @[[User:Uzume|Uzume]]: Got it. Then I am short of ideas for now. If you think your solution, even if it only partially solves the “> 99 parameters problem”, is better than the current <code>:newChild()</code>, we can think of using it. We can follow your suggestion of creating a [[Module:Params/invoke]] submodule – or, if you have any idea of other modules that might be interested in the same machinery, we could also create a top-level [[Module:FrameSpoof]]. I just updated [[Module:Params]] today (with totally unrelated things), so let's wait some time between updates. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:30, 30 September 2025 (UTC) ::::::::::::: @[[User:Uzume|Uzume]]: I have a curiosity (but just if it does not bother you). Previously we talked about how a module can detect whether it is called via wikitext or via Lua. I created a dummy <code>foobar</code> function at [[Module:Sandbox/Grufo2]], then I called it via {{mfl|params|concat_and_invoke}} at [[Module:Params/testcases/sandbox]]. Would you be able to edit such a <code>foobar</code> function so that it returns “Yay!” if it detects it is being called via {{mwl|invoke|}} and “Nay!” if it detects it is being called via {{mfl|params|concat_and_invoke}}? --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 01:48, 3 October 2025 (UTC) ::::::::::::::@[[User:Grufo|Grufo]]: Yes, that is a very simple request. There are a number of ways to detecting such things. One way that is very difficult to get around is to detect how the Scribunto module is loaded. [[Module:Sandbox/Grufo]] gives good examples of such detection splitting out {{code|require}} and {{code|mw.loadData}} vs. {{code|#invoke}} and the {{code|console}}. Anyway, I made the edit you requested via the simplest means (in this case testing {{code|...}} during the module initialization), see [[Special:Diff/1314758676/prev|1314758676]]. Note, this does not specifically detect if it is loaded from wikitext or via Lua as one {{em|can}} call a real {{code|#invoke}} from Lua using <code>[[mw:LUAREF#frame:callParserFunction|frame:callParserFunction]]</code> —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 02:50, 3 October 2025 (UTC) ::::::::::::::: Thank you a lot, [[User:Uzume|Uzume]]. Luckily there is always solution #3 for those picky modules that check (I just edited [[Module:Params/testcases/sandbox]]). --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 11:28, 3 October 2025 (UTC) ::::::::::::::::@[[User:Grufo|Grufo]]: Yes, that is exactly it. With the simplistic and straightforward {{code|newChild()|lua}} based emulation implemented in {{mfl|params|concat_and_invoke}} there are also many other ways to detect such. For example, since such an implementation is loading the target module via {{code|require()|lua}}, its initialization block is cached and only executed once. Package functions in the target module could change variables in either the global or target module spaces and notice their package functions are being executed multiple times. Perhaps a bigger issue is with target module code that uses <code>[[mw:LUAREF#mw.getCurrentFrame|mw.getCurrentFrame]]</code> as that will {{strong|not}} return the frame value passed to the target package function (i.e, that you are creating via {{code|newChild()|lua}}). You balk at the code size of my "frame spoof" based emulation but the majority of its size is actually comments—most of which I added to help you understand how it works or why it is implemented a certain way. These could be removed or at least significantly pared-down. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 12:54, 3 October 2025 (UTC) ::::::::::::::::: Thank you, [[User:Uzume|Uzume]]. I promise you that my next message to you will be after having studied your code. --[[User:Grufo|Grufo]] ([[User talk:Grufo|talk]]) 13:35, 3 October 2025 (UTC) ::::::::::::::::::@[[User:Grufo|Grufo]]: Towards that end I recommend you read [[Module:Sandbox/Grufo]] as that has the most up-to-date version of my {{code|pkgAPI.invoke()|lua}} function. I am sure you will have many questions. —[[User:Uzume|Uzume]] ([[User talk:Uzume|talk]]) 13:50, 3 October 2025 (UTC) == Not a sustainable approach to templates == @[[User:Grufo|Grufo]]: On the one hand, this is cool. I like programming, and [[Module:Params]] is obviously super powerful. But it's not a good choice for a place like Wikipedia. It's simply too complex. Basically, you've created another programming language. When I see stuff like <code>entering_substack</code>, I think of [[Forth (programming language)]]. :-) The main problem is: Nobody but you will be able to maintain a template like [[Template:Universal page list with custom separators]]. But Wikipedia is based on collaboration by (mostly) non-expert volunteers. We need code that is readable and writable by a large number of users. We should stick with Lua modules and Mediawiki templates, and the code should be kept relatively simple. I'm sorry, and I admire your work on [[Module:Params]], but I don't think it's going to be a good fit. — [[User:Chrisahn|Chrisahn]] ([[User talk:Chrisahn|talk]]) 14:22, 16 October 2025 (UTC) == Copied discussion == @[[ಬಳಕೆದಾರೆ:Grufo|Grufo]]: I stumbled on this copied talk page. I thought you might be interested if you ever want to come back and read some of this. —[[ಬಳಕೆದಾರೆ:Uzume|Uzume]] ([[ಬಳಕೆದಾರೆ ಪಾತೆರ:Uzume|ಪಾತೆರ್ಲೆ]]) ೦೫:೪೮, ೧೩ ಜುಲಾಯಿ ೨೦೨೬ (IST) : Indeed. This module has been copied around quite a bit :-) --[[ಬಳಕೆದಾರೆ:Grufo|Grufo]] ([[ಬಳಕೆದಾರೆ ಪಾತೆರ:Grufo|ಪಾತೆರ್ಲೆ]]) ೧೪:೫೮, ೧೩ ಜುಲಾಯಿ ೨೦೨೬ (IST) hpxg3401k7l0mhgxxtwwks2cvvev3yy ಬಳಕೆದಾರೆ:Hariprasad Shetty10/ಕಲ್ಪುನಕಳ 2 24391 362742 362658 2026-07-13T07:12:33Z Hariprasad Shetty10 6127 362742 wikitext text/x-wiki {{Infobox person | name = ಡಾ. ತುಂಬೆ ಮೊಯ್ದೀನ್ | image = ThumbayMoideen.jpg | caption = ಡಾ. ತುಂಬೆ ಮೊಯ್ದೀನ್ | birth_date = {{Birth date and age|1957|3|23|df=yes}} | birth_place = [[ಮಂಗಳೂರು]], ಕರ್ನಾಟಕ, ಭಾರತ | occupation = ತುಂಬೆ ಗ್ರೂಪ್-ದ ಸ್ಥಾಪಕ ಅಧ್ಯಕ್ಷೆರ್ | employer = ತುಂಬೆ ಗ್ರೂಪ್ | known_for = ತುಂಬೆ ಗ್ರೂಪ್, ಗಲ್ಫ್ ಮೆಡಿಕಲ್ ಯೂನಿವರ್ಸಿಟಿ | spouse = ಜೋಹ್ರಾ ಮೊಯ್ದೀನ್ | children = ಅಕ್ಬರ್ ಮೊಯ್ದೀನ್ ತುಂಬೆ<br>ಅಕ್ರಮ್ ಮೊಯ್ದೀನ್ ತುಂಬೆ<ref name="Vignesh">{{cite web |last=Unadkat |first=Vignesh |title=Mr. Thumbay Moideen – Mangalorean Star, April 2020 |website=Mangalorean.com |url=http://www.mangalorean.com/browsearticles.php?arttype=mom&momid=66 }}</ref> | website = {{URL|http://www.thumbaymoideen.com}}<br>{{URL|http://www.thumbay.com}} }} '''ತುಂಬೇ ಮೊಯಿದೀನ್''' (ಪುಟ್ಟು ೨೩ ಮಾರ್ಚ್ ೧೯೫೭) ಯುನೈಟೆಡ್ ಅರಬ್ ಎಮಿರೇಟ್ಸ್ ದ [[ದುಬೈ]] ಡ್ ನೆಲೆಯಾತಿನ ಒರಿ ಭಾರತೀಯ ಉದ್ಯಮಿ. [[ದುಬೈ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಫೈನಾನ್ಶಿಯಲ್ ಸೆಂಟರ್]] ಡ್ ಕೇಂದ್ರ ಕಚೇರಿ ಇಪ್ಪುನ ಒಂಜಿ ವೈವಿಧ್ಯಮಯ ಅಂತರರಾಷ್ಟ್ರೀಯ ವ್ಯಾಪಾರ ಸಂಘಟನೆ ಆಯಿನ [[ಥಂಬೆ ಗ್ರೂಪ್]] ದ ಸ್ಥಾಪಕೆರ್ ಬೊಕ್ಕ ಅಧ್ಯಕ್ಷೆರ್,<ref name="Thumbay Moideen">{{Cite web|title = Thumbay Moideen|url = http://wcrcleaders.com/thumbay-moideen/ |website=wcrcleaders.com |access-date = 2015-09-12}}</ref> with operations across 20 sectors. ==ಸುರುತ ವರ್ಷೊಲು== ಡಾ.ಮೊಯಿದೀನ್ ಮಾರ್ಚ್ ೨೩, ೧೯೫೭ಡ್ [[ಮಂಗಳೂರು]], [[ಭಾರತ]]ಡ್ [[ಬಿ ಅಹ್ಮದ್ ಹಜೀ ಮೊಹಿದೀನ್|ಅಹಮದ್ ಹಜೀ ಮೊಹಿದೀನ್]] ಬೊಕ್ಕ ಅರೆನ ಮದಿಮೆದ ಪೊಣ್ಣು ಬೀ ಫಾತಿಮಾ ಅಹ್ಮದ್ ಹಜೀನ ಇಲ್ಲಡ್ ಪುಟ್ಟುವೆರ್. ಕುಡ್ಲದ ಒಂಜಿ ಪುದರ್ ಪೋಯಿನ ವ್ಯಾಪಾರ ಕುಟುಂಬೊದ ಮೂಜಿನೆ ತರೆಮರೆದ ಉದ್ಯಮಿ, 21 ವರ್ಸೊದ ಡಾ.ಮೊಯಿದೀನ್ ಅಪ್ಪೆ ಸ್ಥಾಪನೆ ಮಲ್ತಿನ ವ್ಯಾಪಾರ ಇಲ್ಲ್ ದ ಲಗಾಮುನ್ ತನ್ನ ಕೈಕ್ ದೆತೊನುವೆರ್.<ref>{{cite web |url = http://www.theintelligentsme.com/2015/06/thumbay-moideen-the-enterprising-visionary/|title = Thumbay Moideen, the enterprising visionary|date = June 2015|publisher = Intelligent SME|access-date =2015-08-29}}</ref> ==ವೃತ್ತಿಜೀವನ== ಡಾ. ಮೊಯಿದೀನ್ 1998ಡ್ [[ಥಂಬೇ ಗ್ರೂಪ್]], ಯುಎಇ ([[ಯುನೈಟೆಡ್ ಅರಬ್ ಎಮಿರೇಟ್ಸ್]]) ನ್ ಸುರು ಮಲ್ತ್ ದ್ [[ಅರೇಬಿಯನ್ ಗಲ್ಫ್|ಪರ್ಷಿಯನ್ ಗಲ್ಫ್ ದ ಅರಬ್ ರಾಜ್ಯೊಲೆಗ್] ಕುಟುಂಬದ ವ್ಯವಹಾರೊನು ತೂಪೆರ್. ಯುಎಇ ಸಂಸ್ಥೆಡ್ ವೈದ್ಯಕೀಯ ಸುರು ಮಲ್ಪೆರೆ [[ಅಜ್ಮಾನ್]] ದ ಆಡಳಿತೆರ್ ಆಹ್ವಾನಿಸಾಯಿನ ಸುರುತ ವಲಸೆ ಬತ್ತಿನಕುಲು.<ref name="Thumbay Moideen"/> ಅಂಚ, [[ಗಲ್ಫ್ ಮೆಡಿಕಲ್ ಯೂನಿವರ್ಸಿಟಿ]] ಸ್ಥಾಪನೆ ಆಂಡ್, ಉಂದು ಅಂಚನೆ 80 ದೇಶೊಲೆಡ್ದ್ ವಿದ್ಯಾರ್ಥಿಲೆಗ್ ವೈದ್ಯಕೀಯ ಶಿಕ್ಷಣೊಗು ಒಂಜಿ ಗಮ್ಯಸ್ಥಾನ ಆಂಡ್.<ref>{{Cite news|url=https://fridaymagazine.ae/life-culture/people-profiles/how-thumbay-moideen-became-a-uae-healthcare-giant-1.2274481|title=How Thumbay Moideen became a UAE healthcare giant|access-date=2018-09-09|language=en-US}}</ref><ref>{{Cite web | url = http://www.gulfnews247.com/2015/11/09/gulf-medical-university-holds-7th-annual-scientific-meeting/ | title = Gulf Medical University Holds 7th Annual Scientific Meeting | website = Gulf News 24/7 | access-date = 2016-03-01 }}</ref><ref>{{Cite web|title = Ajman with a plan|url = http://www.arabianbusiness.com/ajman-with-plan-519094.html |website=arabianbusiness.com |date = 21 September 2013 |access-date = 2015-08-29 }}</ref> ಮೊಯಿದೀನ್ ನ ವ್ಯವಹಾರ ತತ್ವಶಾಸ್ತ್ರ ವೈದ್ಯಕೀಯ ಶಿಕ್ಷಣ, ಆರೋಗ್ಯ ರಕ್ಷಣೆ ವಿತರಣೆ ಬೊಕ್ಕ ಸಂಶೋಧನೆನ್ ಒಂಜೇ ಪರಿಸರ ವ್ಯವಸ್ಥೆಡ್ ಒಟ್ಟು ಸೇರಾವುನ ಮಿತ್ತ್ ಕೇಂದ್ರೀಕೃತವಾದುಂಡು. ಯುಎಇದ ಸುರುತ ಖಾಸಗಿ ವೈದ್ಯಕೀಯ ಕಾಲೇಜಿನ್ ಸ್ಥಾಪನೆ ಮಲ್ಪುನಗ, ಆರ್ ಗುಂಪುನ್ ಬೋಧನಾ ಆಸ್ಪತ್ರೆಲು, ರೋಗನಿರ್ಣಯ ಪ್ರಯೋಗಾಲಯೊಲು, ಚಿಲ್ಲರೆ ಔಷಧಾಲಯೊಲು ಬೊಕ್ಕ ಸಂಶೋಧನಾ ಸಂಸ್ಥೆಲೆನ್ ಸೇರಾದ್ ವಿಸ್ತಾರ ಮಲ್ತೆರ್, ಈ ಪ್ರದೇಶೊದ ಮಲ್ಲ ಖಾಸಗಿ ಶೈಕ್ಷಣಿಕ ಆರೋಗ್ಯ ಜಾಲೊಲೆನ್ ರಚನೆ ಮಲ್ತೆರ್.<ref name=":0">{{Cite web |title=The Unique, Iconic and Trendsetting Visionary Behind Thumbay Group |url=https://livinggulf.com/thumbay-moideen-visionary-behind-thumbay-group/ |url-status=live}}</ref> ೧೯೯೮ಡ್ ಥಂಬೆ ಗ್ರೂಪ್ ಸ್ಥಾಪನೆಡ್ದ್ ಸುರು ಮಲ್ತ್ದ್, ಆರ್ ೨೦ ಕ್ಷೇತ್ರೊಲೆಡ್ ವ್ಯವಹಾರೊಲೆನ್ ಸುರು ಮಲ್ತೆರ್. ಇನಿ, ಈ ಗುಂಪು ಶಿಕ್ಷಣ, ಆರೋಗ್ಯ, ವೈದ್ಯಕೀಯ ಸಂಶೋಧನೆ, ರೋಗನಿರ್ಣಯ, ಚಿಲ್ಲರೆ ಔಷಧಾಲಯ, ಆರೋಗ್ಯ ಸಂವಹನೊಲು, ಚಿಲ್ಲರೆ ಆಪ್ಟಿಕಲ್, ಸ್ವಾಸ್ಥ್ಯ, ಪೌಷ್ಟಿಕಾಂಶ ಅಂಗಡಿಲು, ಆತಿಥ್ಯ, ರಿಯಲ್ ಎಸ್ಟೇಟ್, ಪ್ರಕಟಣೆ, ತಂತ್ರಜ್ಞಾನ, ಮಾಧ್ಯಮ, ಘಟನೆಲು, ವೈದ್ಯಕೀಯ ಪ್ರವಾಸೋದ್ಯಮ ವ್ಯಾಪಾರ, ಮಾರ್ಕೆಟಿಂಗ್ ಬೊಕ್ಕ ವಿತರಣೆಡ್ ವೈವಿಧ್ಯಮಯ ಆಸಕ್ತಿಲೆನ್ ಪಡೆಯಿನ ಒಂಜಿ ವ್ಯವಹಾರ ಗುಂಪು ಆದ್ ಅಭಿವೃದ್ಧಿ ಆತ್ಂಡ್. ಯುಎಇಡ್ ಈ ಸಂಸ್ಥೆ 5,000 ಜನ ಉದ್ಯೋಗಿಲೆನ್ ಕೆಲಸೊಗು ದೀವೊಂದುಂಡು.<ref>{{Cite web|title = Thumbay group named as the Emirates Business Ambassador for healthcare and education – THUMBAY Group News|url = http://www.thumbay.com/news/thumbay-group-named-as-the-emirates-business-ambassador-for-healthcare-and-education/|website = www.thumbay.com|access-date = 2015-09-15}}</ref> ೨೦೧೬ಡ್, ಫೋರ್ಬ್ಸ್ ಮಿಡ್ಲ್ ಈಸ್ಟ್ ಡ್ "ದಿ ಟಾಪ್ ಇಂಡಿಯನ್ ಬಿಸಿನೆಸ್ ಲೀಡರ್ಸ್ ಇನ್ ದಿ ಅರಬ್ ವರ್ಲ್ಡ್" ಡ್ ೧೬ನೇ ಸ್ಥಾನೊಡು ಉಲ್ಲೆರ್.<ref>{{Cite web|url=http://www.forbesmiddleeast.com/en/lists/people/pname/thumbay-moideen/pid/89168/|title=Thumbay Moideen - The Top Indian Business Leaders in The Arab World 2016 (Owners) {{!}} Forbes Middle East|last=Team|first=Forbes|access-date=2016-07-30}}</ref> ಸಮುದಾಯ ಸೇವೆ ಬೊಕ್ಕ ವೈದ್ಯಕೀಯ ಆರೈಕೆನ್ ಒದಗಾಯಿನ ಥುಂಬೇ ಆಸ್ಪತ್ರೆ ಫುಜೈರಾದ 17 ವರ್ಷೊಲೆನ್ ಈ ಗುಂಪು ಆಚರಣೆ ಮಲ್ತ್ಂಡ್.<ref>{{Cite web |title=Thumbay Hospital Fujairah celebrates 17 years of excellence in healthcare, community service |url=https://www.daijiworld.com/news/newsDisplay?newsID=1096349 |access-date=2023-09-08 |website=www.daijiworld.com |language=en}}</ref> ಶಿಕ್ಷಣ ಬೊಕ್ಕ ಆರೋಗ್ಯ ರಕ್ಷಣೆಡ್ ಮಲ್ತಿನ ಬೇಲೆಗ್ ಆರ್ ಬೇತೆ ಬೇತೆ ಅಂತರರಾಷ್ಟ್ರೀಯ ವಿಶ್ವವಿದ್ಯಾಲಯೊಲೆಡ್ದ್ 5 ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಲೆನ್ ಪಡೆಯೆರ್. ==ಸಂಘಟನೆ ಬೊಕ್ಕ ಸಮುದಾಯ ನಾಯಕತ್ವ== ಡಾ. ಮೊಯಿದೀನ್ ಅಜ್ಮಾನ್ ಇಂಡಿಯನ್ ಅಸೋಸಿಯೇಷನ್, ಇಂಡಿಯನ್ ಬಿಸಿನೆಸ್ ಕೌನ್ಸಿಲ್ – ಅಜ್ಮಾನ್, ಬೇರಿಸ್ ಅಸೋಸಿಯೇಷನ್ ​​– ದುಬೈ, ಬೊಕ್ಕ [[ಕರ್ನಾಟಕ]] ಸಂಘ – ಶಾರ್ಜಾದ ಮುಖ್ಯ ಪೋಷಕೆರ್. ಏಷ್ಯಾದ ಆಸ್ಪತ್ರೆ ಒಕ್ಕೂಟದ ಅಧ್ಯಕ್ಷೆರ್ - ಯುಎಇ ಪ್ರದೇಶ, [[ಅಂತರರಾಷ್ಟ್ರೀಯ ಆಸ್ಪತ್ರೆ ಒಕ್ಕೂಟ]], ಫೆರ್ನಿ ವೋಲ್ಟೇರ್, ಫ್ರಾನ್ಸ್ (ಗ್ರೇಟರ್ ಜಿನೀವಾ ಪ್ರದೇಶ), ಬೊಕ್ಕ [[ಅಂತರರಾಷ್ಟ್ರೀಯ ವಿಶ್ವವಿದ್ಯಾಲಯದ ಅಧ್ಯಕ್ಷೆರೆನ ಸಂಘ]] ದ ಸದಸ್ಯೆರ್.<ref>{{Cite web|url=http://www.temos-worldwide.com/index.php?option=com_content&task=view&id=254&Itemid=1|title=Temos - Thumbay Moideen|website=www.temos-worldwide.com|archive-url=https://web.archive.org/web/20150924114151/http://www.temos-worldwide.com/index.php?option=com_content&task=view&id=254&Itemid=1|archive-date=24 September 2015|url-status=dead|access-date=2015-08-29}}</ref> ನವೆಂಬರ್ ೨೦೨೫ಡ್, ಡಾ ಥಂಬಾಯ್ ಮೊಯಿದೀನ್ ನ್ ಗುರುತಿಸಯೆರ್[https://world.einnews.com/pr_news/india/865521474/dr-thumbay-moideen-honored-among-the-top-100-muslims-in-the-world “Top 100 Muslims in the World”] ಶಿಕ್ಷಣ, ಆರೋಗ್ಯ ಬೊಕ್ಕ ಸಮುದಾಯ ಅಭಿವೃದ್ಧಿಗ್ ಅರೆನ ವ್ಯಾಪಕ ಕೊಡುಗೆಲೆನ್ ಗೌರವಿಸವುನ ನಿಟ್ಟಿಡ್. ಆರ್ ಗಲ್ಫ್ ಡ್ ಅತ್ಯಂತ ಗೌರವಾನ್ವಿತ ಎನ್ಆರ್ಐ ಬಿಲಿಯನೇರ್ ಆದ್ ಲಾ ಉಲ್ಲೆರ್.<ref>{{Cite web |title=Gulf Medical University From the No.1 private medical university in the Gulf to the leading institute in the world |url=https://medgatetodayglobal.com/gulf-medical-universityfrom-the-no-1-private-medical-university-in-the-gulf-to-the-leading-institute-in-the-world/}}</ref> '''ಅರೆನ್ ಗಲ್ಫ್ ಡ್ ಕರ್ನಾಟಕೊಡ್ದ್ ಅತ್ಯಂತ ಶ್ರೀಮಂತ ಬೊಕ್ಕ ನಂಬರ್ 1 ಎನ್ಆರ್ಐ ಪಂಡ್ದ್ ಲೆಪ್ಪುವೆರ್.'''<ref name=":0" /> == ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಪ್ರದಾನ == [[File:Dr. Thumbay Moideen.jpg|thumb|ತುಂಬೇ ಗ್ರೂಪ್ ನ ಸ್ಥಾಪಕ ಅಧ್ಯಕ್ಷರು, ತುಂಬೇ ಮೊಯಿದೀನ್ಅಮಿಟಿ ವಿಶ್ವವಿದ್ಯಾಲಯದ ಸ್ಥಾಪಕ ಅಧ್ಯಕ್ಷೆರ್ - ಡಾ. ಅಶೋಕ್ ಕೆ. ಚೌಹಾನ್, ಕುಲಪತಿ - ಡಾ. ಅತುಲ್ ಚೌಹಾನ್, ಅಮಿಟಿ ಪೆಸಿಫಿಕ್ ಫೋರಮ್ ನ ಅಧ್ಯಕ್ಷೆರ್ - ಡಾ. ಅಜಿತ್ ಕುಮಾರ್ ನಾಗ್ಪಾಲ್, ಬೊಕ್ಕ ಇತರ ಅಧಿಕಾರಿಲೆಡ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಪದವಿನ್ ಪಡೆಯೊಂದುಲ್ಲೆರ್.]] ನವೆಂಬರ್ ೨೦೧೭ಡ್ [[ಅಮಿಟಿ ವಿಶ್ವವಿದ್ಯಾಲಯ ದುಬೈ|ಅಮಿಟಿ ವಿಶ್ವವಿದ್ಯಾಲಯ]] – ದುಬೈದ ವಾರ್ಷಿಕ ಘಟನಾ ಸಮಾರಂಭೊಡು ಅರೆಗ್ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಪದವಿನ್ ಕೊರ್ತೆರ್. ಅಮಿಟಿ ವಿಶ್ವವಿದ್ಯಾಲಯ ದುಬೈದ ಅಧಿಕೃತ ಹೇಳಿಕೆಡ್ ಶ್ರೀ ಥಂಬಾಯ್ ಮೊಯಿದೀನ್ ಗ್ ಅರೆನ “ವೈದ್ಯಕೀಯ ಪ್ರಚಾರೊಗು ಮಹತ್ವದ ಕೊಡುಗೆಲೆನ್ ತೂದು ಈ ಗೌರವೊನು ಕೊರ್ತೆರ್ ಪಂಡ್ದ್ ಪನ್ಪೆರ್ [[] ರಾಷ್ಟ್ರದ ಸಾಮಾಜಿಕ ಬೊಕ್ಕ ಆರ್ಥಿಕ ಅಭಿವೃದ್ಧಿ.” === ಗೌರವ ಡಾಕ್ಟರೇಟ್ === ಶಿಕ್ಷಣ, ಆರೋಗ್ಯ, ವ್ಯವಹಾರ, ಬೊಕ್ಕ ಲೋಕೋಪಕಾರೊಗು ಕೊರ್ತಿನ ಕೊಡುಗೆಲೆನ್ ಗುರುತಿಸಾದ್, ಥಂಬಾಯ್ ಮೊಯಿದೀನ್ ಗ್ ವಿವಿಧ ಅಂತರರಾಷ್ಟ್ರೀಯ ವಿಶ್ವವಿದ್ಯಾಲಯೊಲು ಐನ್ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಲೆನ್ ಕೊರ್ತೆರ್. ಈ ಗೌರವೊಲು ಶೈಕ್ಷಣಿಕ ಶ್ರೇಷ್ಠತೆ, ಆರೋಗ್ಯ ರಕ್ಷಣೆದ ನಾವೀನ್ಯತೆ ಬೊಕ್ಕ ಅಡ್ಡ-ಸಾಂಸ್ಕೃತಿಕ ಸಹಯೋಗೊನು ಉತ್ತೇಜಿಸವುನ ಸಂಸ್ಥೆಲೆನ್ ಸ್ಥಾಪನೆ ಮಲ್ಪುನ ಅರೆನ ಪಾತ್ರೊನು ಒಪ್ಪೊನುವೆರ್. * ಥಂಬಾಯ್ ಮೊಯಿದೀನ್ ಗ್ [[ಅಮಿಟಿ ವಿಶ್ವವಿದ್ಯಾಲಯ ದುಬೈ]] 2017ಡ್ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಪ್ರಶಸ್ತಿ ಕೊರ್ತೆರ್ * [[ಚಿತ್ಕಾರ ವಿಶ್ವವಿದ್ಯಾಲಯ, ಪಂಜಾಬ್|ಚಿತ್ಕರ ವಿಶ್ವವಿದ್ಯಾಲಯ]] ಸಾಹಿತ್ಯದ ಡಾಕ್ಟರ್ (ಗೌರವ ಕಾಸಾ) ಪ್ರಶಸ್ತಿ ಕೊರ್ತುಂಡು. * ಫೆರ್ಗಾನಾ ಮೆಡಿಕಲ್ ಇನ್ಸ್ಟಿಟ್ಯೂಟ್ (ಉಜ್ಬೇಕಿಸ್ತಾನ್) ಡ್ದ್ 2025ಡ್ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ನ್ ಪಡೆಯೆರ್ * ಆರ್ [[ಮಂಗಳೂರು ವಿಶ್ವವಿದ್ಯಾನಿಲಯ]] ಡ್ದ್ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ಪಡೆಯೆರ್. * ಪೋಲೆಂಡ್ ದ ಲುಬ್ಲಿನ್ ವಿಶ್ವವಿದ್ಯಾಲಯೊಡ್ದ್ 5ನೇ ಗೌರವ ಡಾಕ್ಟರೇಟ್ ನ್ ಗೌರವಿಸಯೆರ್. ==ಬೇತೆ ಪ್ರಶಸ್ತಿ ಬೊಕ್ಕ ಮಾನ್ಯತೆ== [[File:Dr Thumbay Moideen, President, Gulf Medical University and Dr Edmond Fernandes, Director, Edward & Cynthia Institute of Public Health.jpg|thumb|Dr Moideen and Dr. Edmond Fernandes meet at GMU Headquarters]] [[File:AbdulKalamThumbayMoideenatGMU.jpg|thumb|Late President Kalam with Dr. Moideen during an inaugural event]] ಡಾ. ತುಂಬೆ ಮೊಯಿದೀನ್ ಪ್ರತಿಷ್ಠಿತ ‘[[ಬಾರ್ಕ್ಲೇಸ್]] ಹುರುನ್ ಇಂಡಿಯಾ ರಿಚ್ ಲಿಸ್ಟ್ 2018’ ಡ್ 59ನೇ ಸ್ಥಾನೊಡು ಉಲ್ಲೆರ್.<ref>{{Cite web|url=http://www.mangaloretoday.com/gulfnews/Dr-Thumbay-Moideen-is-ranked-59th-in-Barclays-Hurun-India-Rich-List-2018.html|title=Dr.Thumbay Moideen is ranked 59th in Barclays Hurun India Rich List -2018|website=www.mangaloretoday.com|access-date=2019-03-14}}</ref> ೨೦೧೭ಡ್, ಥುಂಬೇ ಮೊಯಿದೀನ್ ನ್ ಫೋರ್ಬ್ಸ್ ಮಿಡ್ಲ್ ಈಸ್ಟ್ ಡ್ "ದಿ ಟಾಪ್ ಇಂಡಿಯನ್ ಬಿಸಿನೆಸ್ ಲೀಡರ್ಸ್ ಇನ್ ದಿ ಅರಬ್ ವರ್ಲ್ಡ್" ಡ್ ೧೨ನೇ ಸ್ಥಾನೊಡು ದೀಯೆರ್.<ref>{{Cite web|url=http://www.khaleejtimes.com/business/local/here-are-the-top-indian-business-leaders-in-the-arab-world-|title=Here are the top Indian business leaders in the Arab world|last=John|first=Issac|website=www.khaleejtimes.com|access-date=2017-07-30}}</ref> ಡಾ. ಮೊಯಿದೀನ್ 2014 ಡ್ದ್ 2017 ಮುಟ್ಟ ಸತತ ನಾಲ್ ವರ್ಷೊಗು [[ಫೋರ್ಬ್ಸ್]] ಮಧ್ಯಪ್ರಾಚ್ಯ ಪತ್ರಿಕೆದ "ಅರಬ್ ಲೋಕೊಡು ಅಗ್ರ ಭಾರತೀಯ ನಾಯಕೆರ್" ಇಂಚಿನ ವಿವಿಧ ಪಟ್ಟಿಲೆಡ್ ತೋಜಿದ್ ಬೈದೆರ್.<ref>{{Cite news|url=http://www.forbesmiddleeast.com/en/list/top-indian-leaders-in-the-arab-world/|title=Top 100 Indian Business Owners In The Arab World 2017 - Forbes Middle East|last=amro|work=Forbes Middle East|access-date=2017-07-30|language=en-US}}</ref><ref>{{Cite web|url=http://www.forbesmiddleeast.com/en/lists/people/pname/thumbay-moideen/pid/10291/|title=Top Indian leaders in the Arab World 2014 : Top Owners {{!}} Forbes Middle East|last=Team|first=Forbes|website=Forbes Middle East|access-date=2015-08-29}}</ref><ref>{{Cite web|url=http://www.forbesmiddleeast.com/en/lists/people/pname/thumbay-moideen/pid/84029/|title=Thumbay Moideen - Top Indian Leaders in the Arab World 2015|last=Team|first=Forbes|website=Forbes Middle East|access-date=2015-08-29}}</ref><ref>{{Cite web|url=http://tradearabia.com/news/MEDIA_306235.html|title=Thumbay Moideen features on key Forbes list|website=tradearabia.com|access-date=2016-07-30}}</ref> ಅರೇಬಿಯನ್ ಬಿಸಿನೆಸ್ 50 ರಿಚೆಸ್ಟ್ ಇಂಡಿಯನ್ಸ್ ಇನ್ ದ [[ಗಲ್ಫ್ ಕೋಆಪರೇಷನ್ ಕೌನ್ಸಿಲ್|ಜಿಸಿಸಿ]] [[ಅರೇಬಿಯನ್ ಬಿಸಿನೆಸ್]] ಮ್ಯಾಗಜಿನ್, ಪ್ರಕಟಣೆ [[ಐಟಿಪಿ ಪಬ್ಲಿಶಿಂಗ್ ಗ್ರೂಪ್]] – 2013, 2014, 2015 ಬೊಕ್ಕ 2016 ಡ್ ಸತತ ನಾಲ್ ವರ್ಷೊಗು<ref>{{Cite web|url=http://www.arabianbusiness.com/revealed-50-richest-indians-in-gcc-2016-621317.html|title=REVEALED: 50 Richest Indians in the GCC 2016|website=Arabian Business|date=15 February 2016 |access-date=2016-03-01}}</ref><ref name="arab-bus-gcc">{{Cite web|url=http://www.arabianbusiness.com/50-richest-indians-in-gcc-488856.html?view=profile&itemid=488536#.VeFNJiWqqko|title=50 Richest Indians in the GCC|website=arabianbusiness.com|access-date=2015-08-29}}</ref> [[ಫೋರ್ಬ್ಸ್]] ಯುಎಇಡ್ ಮಧ್ಯಪ್ರಾಚ್ಯದ ಟಾಪ್ 100 ಭಾರತೀಯ ನಾಯಕೆರ್"<ref>{{Cite web|url=http://www.forbesmiddleeast.com/en/lists/people/pname/thumbay-moideen/pid/78779/|title=Forbes Middle East}}</ref> and Top 100 [Companies] making an impact in the Arab World,<ref name="forbes-group">{{Cite web|url=http://www.forbesmiddleeast.com/en/lists/read/2013/top-100-making-an-impact-in-the-arab/listid/37/|title=Top 100 Making an Impact in the Arab World|work=Forbes Middle East|access-date=2015-10-22|url-status=dead|archive-url=https://web.archive.org/web/20151103150549/http://www.forbesmiddleeast.com/en/lists/read/2013/top-100-making-an-impact-in-the-arab/listid/37|archive-date=3 November 2015|df=dmy-all}}</ref> Top 100 most influential Indians in the Middle East for three consecutive years in 2010, 2011, 2012 as well as in 2014 by [[Arabian Business]] Magazine.<ref>{{Cite web|url=http://www.arabianbusiness.com/the-gcc-s-100-most-powerful-indians-2014-569197.html?view=profile&itemid=569125#.VeF2tSWqqkp|title=The GCC's 100 Most Powerful Indians 2014|access-date=2015-08-29}}</ref> He received ‘The Eminent Aloysian Alumni Award 2016’, jointly organized by his alma mater St. Aloysius College – Mangaluru and the St. Aloysius College Alumni Association (SACAA), in 2016.<ref>{{Cite web|url=http://azadnewsme.com/en/52/2/7435/?LoginUserId=2&AdminAccess=all&previewLang=1&preview=on|title=Thumbay Moideen Receives 'Eminent Aloysian Award', Delivers Aloysian Conclave Address|publisher=Azad News|access-date=2016-07-30}}</ref> He was featured on the cover of the February 2016 issue of Forbes Middle East.<ref>{{Cite web|url=http://www.varthabharati.in/article/english/5497|title=Thumbay Moideen Featured on the Cover of Forbes Middle East|website=Vartha Bharathi- ವಾರ್ತಾ ಭಾರತಿ|date=4 February 2016 |access-date=2016-02-06}}</ref> A Special Report of [[Gulf News]] Focus featured him among the influential Indians in the UAE.<ref>{{Cite web|url=http://www.daijiworld.com/news/news_disp.asp?n_id=147450|title=UAE: Thumbay Moideen in List of Most Influential Indians|website=www.daijiworld.com|access-date=2015-08-29}}</ref> He was also featured in the cover story of International Indian Magazine’s April 2011 issue,<ref>{{Cite journal|date=April 2011|title=Cover story on the personal and profession profile of Mr. Thumbay Moideen, Founder President of Gulf Medical University, Ajman – U.A.E. published in the April, 2011 issue of The International Indian magazine.|url=http://www.thumbay.com/news/cover-story-on-the-personal-and-profession-profile-of-mr-thumbay-moideen-founder-president-of-gulf-medical-university-ajman-u-a-e-published-in-the-april-2011-issue-of-the-international/|format=pdf|volume=18|issue=2|via=THUMBAY Group News|access-date=2015-08-29|journal=The International Indian}}</ref> ಆರೋಗ್ಯ ರಕ್ಷಣೆ ಬೊಕ್ಕ ವೈದ್ಯಕೀಯ ಶಿಕ್ಷಣ ಕ್ಷೇತ್ರೊಡು ಅಮೂಲ್ಯವಾದ್ ಕೊಡುಗೆ ಕೊರ್ನ ಕಾರಣೊಗು [[ಹೌಸ್ ಆಫ್ ಲಾರ್ಡ್ಸ್]], ಯುಕೆಡ್ ಗೌರವೊನು ಪಡೆಯಿನ ಜೊತೆಗೆ.<ref>{{Cite web|url=http://www.dubaidesi.com/moideen-thumbay-gulf-medical-university-ajman-founder-president/|title=Moideen Thumbay – Gulf Medical University, Ajman Founder President|website=dubaidesi.com|access-date=2015-09-12}}</ref><ref>{{Cite web|url=http://www.ibpmuae.com/profiles/Thumbay-Moideen.pdf|title=IBP Profile|website=ibpmuae.com}}</ref> [[NDTV]] ಗಲ್ಫ್ ಇಂಡಿಯನ್ ಎಕ್ಸೆಲೆನ್ಸ್ ಅವಾರ್ಡ್ಸ್ ೨೦೧೬,<ref>{{Cite web |url=https://uaenews247.wordpress.com/2016/12/13/thumbay-moideen-receives-global-leader-honor-at-ndtv-gulf-indian-excellence-awards-2016/ |title=Thumbay Moideen receives 'Global Leader' honor at NDTV Gulf Indian Excellence Awards 2016 |publisher=uaenews247 |date=2016-12-13 |website=uaenews247}}</ref> Indian Innovator Award, Entrepreneur of the Year 2015,<ref>{{Cite web|url=http://www.entrepreneur.com/article/254890|title=The Recap: Indian Innovator Awards 2015|last=Staff|first=Entrepreneur Middle East|website=Entrepreneur|date=12 January 2016 |access-date=2016-02-06}}</ref><ref>{{Cite web|url=https://www.zawya.com/story/Thumbay_Moideen_Wins_the_Indian_Innovator_Award_Entrepreneur_of_the_Year_2015-ZAWYA20151210112408/|title=Thumbay Moideen Wins the Indian Innovator Award, Entrepreneur of the Year 2015 - Zawya|website=www.zawya.com|access-date=2016-02-06}}</ref> 4th Asian Leadership Award (2014),<ref>{{Cite web|title = :: Asian Leadership Awards ::|url = http://www.asianleadershipawards.com/AELA_2014.html|website = www.asianleadershipawards.com|access-date = 2015-08-29}}</ref> award for outstanding contribution to Education at World Chancellor Congress in Mumbai, India (2014),<ref>{{Cite web|title = Thumbay Moideen gets award for education at Mumbai World Congress|url = http://www.daijiworld.com/news/news_disp.asp?n_id=245603|website = www.daijiworld.com|access-date = 2015-08-29}}</ref> Emirates Business Ambassador Award 2014,<ref>{{Cite web|title = Thumbay Group named as Emirates Business Ambassador for Healthcare and Education - AMEInfo|url = http://ameinfo.com/finance-and-economy/economy/healthcare/thumbay-group-named-emirates-business-ambassador-healthcare-education/|access-date = 2015-08-29}}</ref> NGI Excellence Award 2012 at the Global Indian Business Meet (GIBM) New York,<ref>{{Cite news|url = http://www.gibm2012.org/images/gibm-report.pdf |title = GIBM 2012|website=gibm2012.org }}</ref> CEO of the Year – Education Award 2012 by the [[ITP Publishing Group]] UAE,<ref>{{Cite web|title = CEO Middle East Awards 2012|url = http://www.arabianbusiness.com/photos/ceo-middle-east-awards-2012--473654.html?img=4 |website=arabianbusiness.com |access-date = 2015-08-29}}</ref> Mayura Award for achievements in the field of medical education and healthcare by Karnataka Sangha Sharjah, Achievement in the field of Medical Education and Healthcare awarded by [[Sheikh Humaid bin Rashid Al Nuaimi|Sheikh Humaid Bin Rashid Al Nuaimi]], Member of Supreme Council and Ruler of Ajman – UAE, Honorary Fellowship of [[International Medical Sciences Academy]] (IMSA),<ref name="daijiworld.com">{{Cite web|title = Ajman: Thumbay Moideen Conferred Honorary Fellowship of Int'l Medical Science Academy|url = http://www.daijiworld.com/news/news_disp.asp?n_id=152050|website = www.daijiworld.com|access-date = 2015-08-29}}</ref> He received the [[Karnataka Rajyotsava]] Award recently for his contribution to healthcare.<ref>{{Cite web |last=Bharathi |first=Vartha |title=Karnataka Rajyotsava Award announced for Dr. Thumbay Moideen |url=https://english.varthabharati.in/karnataka/karnataka-rajyotsava-award-announced-for-dr-thumbay-moideen |access-date=2025-01-24 |website=english.varthabharati.in |language=en}}</ref> ==Conferences Spoken at== Dr. Moideen has been a speaker at various conferences and seminars held in America, Europe, Middle East and the Indian subcontinent,<ref>{{Cite web|title = Ajman: Thumbay Moideen speaks at International Conference in Turkey|url = http://www.daijiworld.com/news/news_disp.asp?n_id=173835|website = www.daijiworld.com|access-date = 2015-08-29}}</ref> in prestigious programs like the [[Emirates NBD]] Global Business Series - Dubai,<ref>{{Cite web | url = http://www.theintelligentsme.com/2015/06/thumbay-moideen-the-enterprising-visionary/ | title = Upclose & personal with Thumbay Moideen, Founder President of Thumbay Group | website = SME Magazine, SME News, SME Guide, SME Events... | language = en-US | access-date = 2016-03-01 }}</ref> the 1st International Conference on 'Cooperation in Higher Education within the EURAS' held under the auspices of the Eurasian Universities Union (EURAS) - Istanbul,<ref>{{Cite web | url = http://www.thumbay.com/news/mr-thumbay-moideen-speaks-at-the-ist-international-conference-on-cooperation-in-higher-education-within-the-eurasian-universities/ | title = Mr. Thumbay Moideen speaks at the Ist International Conference On Cooperation in Higher Education within the Eurasian Universities – THUMBAY Group News | website = www.thumbay.com | access-date = 2016-03-01 }}</ref> the Vibrant Business Summit - Gandhinagar,<ref>{{Cite web | url = http://www.tradearabia.com/news/BANK_291744.html | title = Dream big, top businessman tells entrepreneurs | website = www.tradearabia.com | access-date = 2016-03-01 }}</ref> the 7th Annual Higher Education Summit Asia – Singapore,<ref>{{Cite web | url = http://www.mangalorean.com/thumbay-moideen-addresses-7th-annual-higher-education-summit-asia-in-singapore/ | title = Thumbay Moideen Addresses '7th Annual Higher Education Summit Asia' in Singapore - Mangalorean.com | website = Mangalorean.com | date = 20 October 2015 | language = en-US | access-date = 2016-03-01 }}</ref> [[World Bank]] – Washington,<ref>{{Cite web | url = http://www.thumbay.com/news/gmu-president-mr-thumbay-moideen-invited-to-speak-at-the-ifc-world-bank-education-of-health-professionals-conference-held-in-washington-dc/ | title = GMU President, Thumbay Moideen invited to speak at the IFC – World Bank 'Education of Health Professionals Conference' held in Washington D.C. – THUMBAY Group News | website = www.thumbay.com | access-date = 2016-03-01 }}</ref> the [[International Association of Universities]] President (IAUP) - [[Tokyo]], etc.<ref>{{Cite web | url = http://www.udupitoday.com/udtoday/news_Thumbay-Moideen-to-speak-at-Trienneal-Conference-in-Tokyo_3758.html | archive-url = https://web.archive.org/web/20140426204754/http://www.udupitoday.com/udtoday/news_Thumbay-Moideen-to-speak-at-Trienneal-Conference-in-Tokyo_3758.html | url-status = usurped | archive-date = 26 April 2014 | title = Thumbay Moideen to speak at Trienneal Conference in Tokyo - Udupi Today | website = www.udupitoday.com | access-date = 2016-03-01 }}</ref><ref>{{Cite web|title = Upclose & personal with Thumbay Moideen, Founder President of Thumbay Group |url=http://www.theintelligentsme.com/2015/06/thumbay-moideen-the-enterprising-visionary/|access-date = 2015-08-29}}</ref> He led the panel discussion on the topic “Time to Bridge the Gulf,” conducted in Dubai as part of the NDTV Gulf Indian Excellence Awards 2016.<ref>{{Cite news|url=http://www.shomosnews.com/thumbay-moideen-receives-global-leader-honor/|title=Thumbay Moideen receives 'Global Leader' honor - بوابة شموس نيوز|date=2016-12-13|newspaper=بوابة شموس نيوز|language=ar-AR|access-date=2016-12-14}}</ref> He was also the keynote speaker at the Leadership & Entrepreneurship Series held at Sharjah Chamber of Commerce and Industry (SCCI) on 6 March 2017, and at the 37th Annual IMASA Convention held at Coastlands Umhlanga Hotel and Convention Centre, Durban, South Africa on 29th & 30 April 2017.<ref>{{Cite web|url=https://www.facebook.com/IMASAConvention2017/photos/ms.c.eJw9kseNRVEIQzsakUP~;jY0~_fr7LI8AmtY2uSLWXVvZfH6uCjRwhNq5FLnCQF6wfm199CLmPnfVuUhtb~_XH4cVLPz8~_W~_YH~_lP2lgJ0cx7Ifl4HZT~_7p~_zAONnLD3~_g~;8A~;6dx8n~;cYRZz8r4G9eFbBz~;u3TlxfXi9uS89dv5pCvvxmyJtjIt4~_kv5qAnYy4M~_5zbEm~_~;U89ht~;zT~;gF~;eruF7yHFuqd9XP7G~;6DYj~;6~_lvky5dvcvq91Md~_hvsxzNuc1zBvUM~;s~;k15X~;O5~;NzHl895re6fQ6iXYLUXv3r~_p~;X89CXtH55Uong~-.bps.a.728189797361684.1073741830.554890581358274/728190320694965/?type=3&theater|title=IMASA Annual Convention|website=www.facebook.com|language=en|access-date=2017-05-09}}</ref> == Thumbay Foundation == Thumbay Foundation is a charitable trust which supports charitable activities in healthcare & education through scholarships, grants, bursaries, awards, fellowships, endowments, donations and other forms of financial assistance to students pursuing any level of education or training in any educational or training institutions or establishments or otherwise in such manner as may be decided by the Foundation.<ref>{{Cite web|title = Thumbay Foundation {{!}} Thumbay Group|url = http://www.thumbay.com/thumbay-foundation|website = www.thumbay.com|access-date = 2015-08-29|publisher=Thumbay Group}}</ref> === Masjids Built by Thumbay Moideen === '''Thumbay Moideen''', the founder and president of the Thumbay Group, has contributed to the construction of several mosques across India and the United Arab Emirates. His efforts reflect his commitment to supporting community, faith, and education. Four notable mosques associated with his philanthropy include: * '''Mohiudeen Masjid, Thumbay (India):''' Located in Thumbay, Karnataka, this mosque serves as a center of worship and community gatherings for the local population. It holds cultural and religious significance for the Thumbay region. * '''B. Ahmed Haji Mohiudeen Masjid, Mangalore (India):''' Established in Mangalore, this mosque stands as a symbol of devotion and service, named in honor of B. Ahmed Haji Mohiudeen. It provides space for daily prayers and religious activities for the Muslim community. * '''Thumbay Moideen Masjid, Ajman (UAE):''' Built in Ajman, this mosque represents Thumbay Moideen’s contributions to the UAE’s religious and cultural landscape. It is frequented by residents and visitors for congregational prayers and community events. * '''Juma Masjid, Sharjah (UAE):''' This Friday mosque (Juma Masjid) in Sharjah is another initiative linked to Thumbay Moideen. Designed to accommodate large gatherings, it plays an important role in the weekly Jumu’ah prayers and religious education. Together, these mosques highlight Thumbay Moideen’s philanthropic vision of fostering spiritual growth and community engagement across both India and the UAE. == Family == Dr. Thumbay Moideen is married to Zohra and they have two sons, [[Akbar Moideen Thumbay]] and Akram Moideen Thumbay. Akbar manages Thumbay Group’s hospitals as the Vice President of the healthcare division, while Akram manages the construction & renovation division as its Director-Operations and also serves as the Director of Thumbay Technologies. Akbar is married to Nousheen Salma, who is in charge of handling the editorial and design advice of ‘Health’ magazine, Thumbay Group’s health and lifestyle publication. Akbar and Nousheen have three sons - Ahmed, Omar and Rashid. ==References== {{reflist}} == External links == * {{Official website|https://thumbaymoideen.com/}} {{DEFAULTSORT:Moideen, Thumbay}} [[Category:Indian philanthropists]] [[Category:Mangaloreans]] [[Category:Living people]] [[Category:Indian Muslims]] [[Category:Businesspeople from Mangalore]] [[Category:Indian expatriates in the United Arab Emirates]] [[Category:1957 births]] 28sgdkgw0xpnzhyvi6vm22x7shvrjgq ವಾಣಿ ಭೋಜನ್ 0 25959 362740 357778 2026-07-13T02:40:50Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362740 wikitext text/x-wiki {{Infobox person | name = Vani Bhojan | image = Vani Bhojan At The ‘Oh My Kadavule’ Press Meet (cropped).jpg | caption = Vani Bhojan in 2020 | birth_date = {{birth date and age|1988|10|28|df=yes}} | birth_place = [[Ooty]], [[Tamil Nadu]], India | alma_mater = [[Government Arts College, Ooty]] ([[Bachelor of Arts|B.A.]] English) | occupation = {{hlist|Actress|model|former Airhostess}} | years_active = 2010-present }} {{Pending films key}}'''ವಾಣಿ ಭೋಜನ್''' [ a ] (ಪುಟ್ಟು ೨೮ ಅಕ್ಟೋಬರ್ ೧೯೮೮) ಒರ್ತಿ ಭಾರತದ ಆಕ್ಟರ್, ಆರ್ ಮುಖ್ಯವಾದ್ ತಮಿಳು ಸಿನಿಮಾಲೆಡ್ ಆಕ್ಟ್ ಮಲ್ತೆರ್. <ref name="Lo">{{Cite news|url=https://www.thehindu.com/entertainment/movies/vani-bhojan-is-to-happy-to-have-made-a-telugu-film-debut-with-meeku-maathrame-cheptha/article29991904.ece|title=Vani Bhojan makes a smooth transition from TV to cinema|last=Chowdhary|first=Y. sunita|date=16 November 2019|work=The Hindu}}</ref> ಮೇರ್ 2019ಡ್ ''ಮೀಕು ಮಾತೃಮೆ ಚೆಪ್ತಾ'' ಚಿತ್ರೊಡು ತೆಲುಗು ಸಿನಿಮಾಡ್ ಆಕ್ಟ್ ಮಲ್ಪೆರೆ ಸುರು ಮಲ್ತೆರ್ ಬೊಕ್ಕ 2020ಡ್ ''ಓಹ್ ಮೈ ಕಡವುಲೆ'' ಚಿತ್ರೊಡು ತಮಿಳು ಸಿನಿಮಾಡ್ ಪಾಲ್ ಪಡೆಯೆರ್. == ಸುರುತ ಜೀವನ ಬೊಕ್ಕ ಕುಟುಂಬ == ಭೋಜನ್ 1988 ಅಕ್ಟೋಬರ್ 28 ತಾರೀಕ್ ಗ್ [[ತಮಿಳುನಾಡು|ತಮಿಳುನಾಡುದ]] ನೀಲಗಿರಿ ಜಿಲ್ಲೆದ [[ಉದಕಮಂಡಲ|ಊಟಿಡ್]] ಬಡಗ ಕುಟುಂಬೊಡು ಪುಟ್ಟುವೆರ್. <ref name="dob">{{Cite web|title=Fans trend 'HBD Vani Bhojan' to celebrate Oh My Kadavule star's 32nd birthday|url=https://www.zoomtventertainment.com/tamil-cinema/article/fans-trend-hbd-vani-bhojan-to-celebrate-oh-my-kadavule-stars-32nd-birthday/674010|accessdate=10 December 2020|website=zoomtventertainment.com|language=en}}</ref> ಆರ್ ಬೋರ್ಡಿಂಗ್ ಸ್ಕೂಲ್, ಊಟಿಡ್ ಶಾಲೆಗ್ ಪೋಯೆರ್ ಬೊಕ್ಕ [[ಉದಕಮಂಡಲ|ಊಟಿದ]] ಸ್ಟೋನ್ ಹೌಸ್ ಹಿಲ್ ಡ್ ಸರ್ಕಾರಿ ಕಲಾ ಕಾಲೇಜಿಡ್ ಇಂಗ್ಲಿಷ್ ಸಾಹಿತ್ಯೊಡು ಕಲೆತ ಬಗೆ ಸ್ನಾತಕೋತ್ತರ ಡಿಗ್ರಿ ನ್ ಮುಗಿತೆರ್. ಭೋಜನ್ ಅರೆನ ಅಮ್ಮೆ ಒರಿ ವನ್ಯಜೀವಿ ಫೋಟೋಗ್ರಾಫರ್. ಭೋಜನ್ ಕಿಂಗ್ ಫಿಶರ್ ಏರ್ಲೈನ್ಸ್ ಬೊಕ್ಕ ಇಂಡಿಗೊಡು ಏರ್ ಹೋಸ್ಟೆಸ್ ಆದ್ ತನ್ನ ಕೆಲಸದ ವೃತ್ತಿಜೀವನೊನು ಸುರು ಮಲ್ತೆರ್, ಒಂಜೇ ಸಮಯೊಡು ಒಂಜಿ ಪತ್ರವ್ಯವಹಾರ ಕಾರ್ಯಕ್ರಮೊದ ಮೂಲಕ ಇಂಗ್ಲಿಷ್ ಸಾಹಿತ್ಯೊಡು ಡಿಗ್ರಿ ತಿಕ್ಕೆರೆ ಅಧ್ಯಯನ ಮಲ್ತೆರ್. ಅಪಗ ಆರ್ ಸ್ಪೈಸ್ ಜೆಟ್ ಡ್ ವ್ಯವಸ್ಥಾಪಕೆರೆನ ಪಾತ್ರೊನ್ ದೆತೊನುನ ಪ್ರಯತ್ನ ಮಲ್ತೆರ್ ಆಂಡ ಆರ್ ತನ್ನ ಡಿಗ್ರಿ ನ್ ಮುಗಿತ್ ಬೆನ್ಪಿನೆಡ್ದಾವರ ಅರೆಗ್ ಸೇರೊಡಾಪುಜಿ, ಬೊಕ್ಕ ಆರ್ ನಿರುದ್ಯೋಗಿ ಆದ್ ಉಂತುದು ಪೋಯೆರ್. ಭೋಜನ್ ದಿ ಚೆನ್ನೈ ಸಿಲ್ಕ್ಸ್ ದ ಎಡ್ವರ್ಡ್ ಡೈಸ್ಡ್ ಮಾಡೆಲ್ ಆದ್ ಬೇಲೆ ಮಲ್ಪೆರೆ ಅವಕಾಶ ಪಡೆಯೆರ್, ಉಂದೆತ ಕಾರಣೊಡು ಅರೆಗ್ ನಟನೆದ ಆಫರ್ ಲು ಬತ್ತ್ಂಡ್. <ref name="W">{{Cite web|date=13 February 2020|title=I'm my own cheer leader during difficult times-Vani Bhojan|url=https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/im-my-own-cheer-leader-during-difficult-times-vani-bhojan/articleshow/74117983.cms|accessdate=1 November 2025|website=The Times of India|archiveurl=https://web.archive.org/web/20200808085943/https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/im-my-own-cheer-leader-during-difficult-times-vani-bhojan/articleshow/74117983.cms|archivedate=8 August 2020}}</ref> <ref>{{Cite web|title="I Don't Have A Degree" – Vani Bhojan Opens For The First Time !! WATCH &#124; Chennai Memes|url=https://www.chennaimemes.in/i-dont-have-a-degree-vani-bhojan-opens-for-the-first-time-watch/|accessdate=2026-03-28|archivedate=2020-10-01|archive-url=https://web.archive.org/web/20201001195057/https://www.chennaimemes.in/i-dont-have-a-degree-vani-bhojan-opens-for-the-first-time-watch/|url-status=dead}}</ref> == ಕೆಲಸ == ನಟಿಯಾದ್ ಅರೆನ ಸುರುತ ಪಾತ್ರ 2010ಡ್, ತಮಿಳು ಭಯಾನಕ ಚಿತ್ರ ''ಒರ್ರ್ ಎರಾವುಡ್'' ಒಂಜಿ ಎಲ್ಯ ಪಾತ್ರೊಡು ನಡತ್ಂಡ್. <ref>{{Cite web|url=https://www.shankarbros.com/orr-eravuu.html|title=Orr Eravuu}}</ref> ೨೦೧೨ಡ್ ತಮಿಳು ಪಿಕ್ಚರ್ ''ಆದಿಗರಂ ೭೯'' ಡ್ ಸಹಾಯಕ ಪಾತ್ರೊಡು ತೋಜಿದ್ ಬತ್ತೆರ್. ನನೊಂಜಿ ಸರ್ತಿ ಅರೆನ್ ವಿಜಯ್ ಟಿವಿದ ಆಹಾ ಬೊಕ್ಕ ಜಯ ಟಿವಿದ ''ಮಾಯಾ'' ಪನ್ಪಿನ ಧಾರಾವಾಹಿಲೆಡ್ ಪಾದಾರ್ಪಣೆ ಮಲ್ತೆರ್. ಈ ಧಾರಾವಾಹಿಲೆಡ್ ಆರ್ ಮುಖ್ಯ ಪಾತ್ರೊಡು ಆಕ್ಟ್ ಮಲ್ತೆರ್. ಮೇರ್ 2013ನೇ ಇಸವಿಡ್ ಸನ್ ಟಿವಿ ಸರಣಿ ''ದೈವಮಗಲ್'' ಡ್ ಮುಖ್ಯ ಪಾತ್ರೊಡು ನಟನೆ ಮಲ್ತೆರ್. <ref>{{Cite web|last=Naig|first=Udhav|last2=Ramakrishnan|first2=Deepa H.|date=29 March 2015|title=Megaserial Milestone|url=http://www.thehindu.com/todays-paper/tp-national/tp-tamilnadu/world-cup-commentary-in-tamil-pays-off-at-last/article7044538.ece?css=print|accessdate=18 October 2020|language=en}}</ref> ಆರ್ ಕೃಷ್ಣನ ಎದುರು ಸತ್ಯ ಪ್ರಿಯ ಪಾತ್ರೊನ್ ಮಲ್ತೆರ್ . <ref name="Y">{{Cite web|date=26 February 2018|title=Deivamagal come to an end|url=https://timesofindia.indiatimes.com/tv/news/tamil/deivamagal-comes-to-an-end/articleshow/63080540.cms|accessdate=22 August 2019|website=The Times of India}}</ref> ಈ ಧಾರಾವಾಹಿದ ಯಶಸ್ಸು ತಮಿಳು ಬೊಕ್ಕ ತೆಲುಗು ಸಿನಿಮಾಲೆಡ್ ಅಭಿನಯ ಮಲ್ಪೆರೆ ಸಹಾಯ ಮಲ್ತ್ಂಡ್. ಝೀ ತಮಿಳು ಡ್ ಸುರೇಶ್ ಕೃಷ್ಣ ಬೊಕ್ಕ ವಿ.ಸಥಾಸಿವಂ ನಿರ್ದೇಶನೊಡು ''ಲಕ್ಷ್ಮೀ ವಂತಾಚು'' ಡ್ ಲಾ ತೋಜಿದ್ ಬತ್ತೆರ್, <ref name="W"/> ಅಲ್ಪ ನಂಧಿನಿ, ಲಕ್ಷ್ಮಿ ಬೊಕ್ಕ ಝಾನ್ಸಿ ಪನ್ಪಿನ ಮೂಜಿ ಪಾತ್ರೊಲೆನ್ ಮಲ್ತೆರ್. <ref>{{Cite web|date=16 August 2015|title=Vani Bhojan pins hope on her new soap|url=https://www.deccanchronicle.com/150816/entertainment-tvmusic/article/vani-bhojan-pins-hope-her-new-soap|accessdate=9 October 2020|website=[[Deccan Chronicle]]}}</ref> <ref>{{Cite news|url=https://timesofindia.indiatimes.com/tv/news/tamil/i-never-came-to-tv-wanting-to-be-a-film-actress-vani-bhojan/articleshow/61981390.cms|title=I never came to TV wanting to be a film actress: Vani Bhojan|date=9 December 2017|work=The Times of India|access-date=20 November 2020|language=en}}</ref> ೨೦೧೭ಡ್, ಮೇರ್ [[ತೆಲುಗು ಬಾಸೆ|ತೆಲುಗು]] ಚಿತ್ರ ''ಪ್ರೇಮಾ'' ಡ್ ತೋಜಿದ್ ಬತ್ತೆರ್. <ref name="E">{{Cite web|date=18 November 2017|title=Prema to premiere directly on television|website=[[The Times of India]]|url=https://timesofindia.indiatimes.com/entertainment/telugu/prema-to-premiere-directly-on-television/articleshow/61702914.cms|accessdate=26 September 2020}}</ref> ದೈವಮಗಲ್ <ref name="Sa">{{Cite web|date=9 March 2020|title=Vani Bhojan is a Judge in Asathal Chutties Sun TV show|website=[[The Times of India]]|url=https://timesofindia.indiatimes.com/topic/asathal-chutties|accessdate=26 September 2020}}</ref> ''ವಂತಾಚುನ್'' ''ಮುಗಿತ್'' ಬೊಕ್ಕ, ಸನ್ ಟಿವಿಡ್ ಅಸತಾಲ್ ಚುಟ್ಟಿಸ್ ಡ್ ನ್ಯಾಯಾಧೀಶೆ ಆದ್ ತೋಜಿದ್ ಬತ್ತೆರ್ . <ref name="P">{{Cite web|date=16 September 2017|title=Kings of Comedy grand-finale|url=https://cinema.dinamalar.com/tamil-tv-serials/62803/Chinna-thirai-Television-News/Kings-of-Comedy-grand-finale.htm|accessdate=26 September 2020|publisher=[[Dinamalar]]}}</ref> ಆಂಡಲಾ, 2019 ದ ಮಧ್ಯೊಡು ದಿನಾಂಕದ ಸಮಸ್ಯೆಲೆನ್ ಉಲ್ಲೇಖ ಮಲ್ತ್ದ್, ಆರ್ ಚಿತ್ರೊಡ್ದ್ ಪಿದಯಿ ಬತ್ತೆರ್. <ref>{{Cite web|last=J|first=Sathish|date=22 June 2019|title=Vani Bojan out of Lokesh's new film!|url=https://movies.ndtv.com/tamil/kollywood/actress-vani-bhojan-dropped-out-of-n-4-directed-by-director-lokesh-2057565|accessdate=20 September 2020|publisher=[[NDTV]]}}</ref> ಅಂಚಾದ್, 2019ಡ್ ತೆಲುಗು ಚಿತ್ರ ''ಮೀಕು ಮಾತೃಮೆ ಚೆಪ್ತಾ ಡ್'' ಥರುನ್ ಭಾಸ್ಕರ್ ನ ಒಟ್ಟುಗು ಮುಖ್ಯ ಪಾತ್ರೊಡು ಸುರುತ ಸರ್ತಿ ತೋಜಿದ್ ಬತ್ತೆರ್. <ref name="Lo"/> ಚಿತ್ರ ಒಂಜಿ ವಾಣಿಜ್ಯ ಯಶಸ್ಸು ಆಂಡ್. <ref name="Op">{{Cite web|date=29 May 2021|title=Television is a place where I've earned my name as an actor: Vani Bhojan|website=[[The Times of India]]|url=https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/television-is-a-place-where-ive-earned-my-name-as-an-actor-vani-bhojan/articleshow/85583187.cms|accessdate=24 August 2021}}</ref> ಭೋಜನ್ ದಿ ಟೈಮ್ಸ್ ಮೋಸ್ಟ್ ಡಿಸೈರಬಲ್ ವುಮೆನ್ ಆನ್ ಟೆಲಿವಿಷನ್ ಡ್ 2017ಡ್ ನಂಬರ್ 1 <ref>{{Cite web|title=Chennai's most desirable Women on Television|url=https://timesofindia.indiatimes.com/tv/news/tamil/chennai-times-15-most-desirable-women-on-television-2018/articleshow/67792954.cms|accessdate=6 August 2017|website=The Times of India|language=en}}</ref> ಬೊಕ್ಕ 2018 ಬೊಕ್ಕ 2019ಡ್ ನಂಬರ್ 3 ಸ್ಥಾನೊಡು ಉಲ್ಲೆರ್ <ref>{{Cite news|url=https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/chennai-times-30-most-desirable-women-2020/articleshow/83147467.cms|title=The Times Most Desirable Women of 2020: Sushant Singh Rajput – Philosopher, dreamer, charmer|work=The Times of India|access-date=6 August 2021|language=en}}</ref> ೨೦೨೦ಡ್, ಅಶೋಕ್ ಸೆಲ್ವನ್ ನ ಎದುರು ತಮಿಳು ಚಿತ್ರ ''ಓಹ್ ಮೈ ಕಡವುಲೆ'' ಡ್ ಪಾದಾರ್ಪಣೆ ಮಲ್ತೆರ್. <ref name="U">{{Cite web|date=14 February 2020|title='Oh My Kadavule' review: Ritika-Ashok's romance is refreshing|url=https://www.thenewsminute.com/article/oh-my-kadavule-review-ritika-ashoks-romance-refreshing-118203|accessdate=14 February 2020|website=News Minute}}</ref> ಉಂದು 2020ಡ್ ಬಾಕ್ಸ್ ಆಫೀಸ್ ಡ್ ಯಶಸ್ವಿ ಆಂಡ್ ಬೊಕ್ಕ ಅರೆನ್ ಅತ್ಯುತ್ತಮ ಪೋಷಕ ನಟಿಗ್ ಸಿಮಾ ಪಂಡ್ದ್ ನಾಮನಿರ್ದೇಶನ ಮಲ್ತೆರ್. <ref>{{Cite web|date=11 February 2020|title=Oh My Kadavule will remain close to my heart: Vani Bhojan|url=https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/oh-my-kadavule-will-remain-close-to-my-heart-vani-bhojan/articleshow/74083833.cms|accessdate=26 September 2020|website=The Times of India}}</ref> ಅವೇ ವರ್ಷ, ಝೀ5 ಡ್ ಬಿಡುಗಡೆ ಆಯಿನ [[ಕೊರೋನಾವೈರಸ್ ಸೀಕ್ ೨೦೧೯|ಕೋವಿಡ್-೧೯]] ಚಿತ್ರೊಗು ಕಾರಣವಾದ್ ವೈಭವ್ ನ ಒಟ್ಟಿಗೆ ಕ್ರೈಮ್ ಥ್ರಿಲ್ಲರ್ ಚಿತ್ರ ''ಲಾಕ್ ಅಪ್'' ಡ್ ಮುಖ್ಯ ಪಾತ್ರೊಡು ತೋಜಿದ್ ಬತ್ತೆರ್ <ref>{{Cite web|last=Subramanian|first=Anupama|date=1 November 2019|title=A film named Lockup|url=https://www.deccanchronicle.com/entertainment/kollywood/311019/a-film-named-lockup.html|archiveurl=https://web.archive.org/web/20200705195135/https://www.deccanchronicle.com/entertainment/kollywood/311019/a-film-named-lockup.html|archivedate=5 July 2020|accessdate=9 October 2020|website=[[Deccan Chronicle]]}}</ref> ಬೊಕ್ಕ ಹಾಟ್ಸ್ಟಾರ್ ಡ್ ಬಿಡುಗಡೆ ಆಯಿನ ಜೈ ಗ್ ಎದುರು [[ತಮಿಳು ಬಾಸೆ|ತಮಿಳು]] ವೆಬ್ ಸರಣಿ ''ಟ್ರಿಪಲ್ಸ್'' . <ref>{{Cite web|url=https://www.firstpost.com/entertainment/disney-hotstar-announces-first-slate-of-tamil-originals-line-up-kicks-off-with-nayantharsa-rj-balajis-diwali-release-8946721.html|title=Disney+ Hotstar announces first slate of Tamil originals; line-up kicks off with Nayantharsa, RJ Balaji's Diwali release}}</ref> 2021ಡ್, ZEE5 ಚಿತ್ರ ''ಮಲೇಷ್ಯಾ ಟು ಅಮ್ನೇಷಿಯಾ ಗ್'' ವೈಭವ್ ನೊಟ್ಟುಗು ಪಿರ ಜೋಡಿಯಾದ್ ಸೇರ್ದೆರ್. ಅಮೆಜಾನ್ ಪ್ರೈಮ್ ಡ್ ಬುಡುಗಡೆ ಆಯಿನ ಸೂರಿಯಾನ 2D ಎಂಟರ್ಟೈನ್ಮೆಂಟ್ ಡ್ದ್ ನಿರ್ಮಾಣ ಆಯಿನ ''ರಾಮೆ ಆಂಡಲಂ ರಾವಣೆ ಆಂಡಲಮ್'' ಡ್ ಅಭಿನಯ ಮಲ್ತೆರ್ ಬೊಕ್ಕ ಈ ಸಿನಿಮಾಡ್ ಪತ್ರಕರ್ತೆ ಆದ್ ನಟನೆ ಮಲ್ತೆರ್. <ref>{{Cite web|date=1 February 2021|title=Ramya Pandian, Vani Bhojan in Suriya's production|url=https://www.dtnext.in/News/Cinema/2021/02/01012152/1273955/Ramya-Pandian-Vani-Bhojan-in-Suriyas-production.vpf|archiveurl=https://web.archive.org/web/20211229080312/https://www.dtnext.in/News/Cinema/2021/02/01012152/1273955/Ramya-Pandian-Vani-Bhojan-in-Suriyas-production.vpf|archivedate=29 December 2021|website=dtNext.in}}</ref> <ref name="Op"/> ಭೋಜನ್ ಕಾರ್ತಿಕ್ ಸುಬ್ಬರಾಜ್ ನ ''ಮಹಾನ್'' (2022) ಚಿತ್ರೊಡು ವಿಕ್ರಮ್ ನ ಪ್ರೀತಿದ ಪಾತ್ರೊಡು ದೃಢಪಡ್ತ್ಂಡ್; ಆಂಡಲಾ ಅಲೆನ ದೃಶ್ಯೊಲು ಅಂತಿಮ ಕಟ್ ಮಲ್ಪುಜಿ. <ref name=":0">{{Cite web|date=13 March 2021|title=After Bobby Simha, Vani Bhojan joins cast of Vikram's 'Chiyaan 60'|url=https://www.thenewsminute.com/article/after-bobby-simha-vani-bhojan-joins-cast-vikrams-chiyaan-60-145166|website=The News Minute}}</ref> ಭೋಜನ್ ನ ದುಂಬುದ ಬಿಡುಗಡೆ ಅರುಣ್ ವಿಜಯ್ ನ ಒಟ್ಟುಗು ಕ್ರೈಮ್ ಥ್ರಿಲ್ಲರ್ ವೆಬ್ ಸೀರಿಸ್ ''ತಮಿಳು ರಾಕರ್ಜ್'' (೨೦೨೨) ಆಂಡ್. ಆರ್ ಒರಿ ಫೋರೆನ್ಸಿಕ್ ಅಧಿಕಾರಿನ ಪಾತ್ರೊನ್ ಮಲ್ತೆರ್. <ref>{{Cite web|date=17 November 2021|title=Vani Bhojan to play lead roles in a thriller film with Arun Vijay|url=https://www.onlykollywood.com/arun-vijay-arivazhagans-web-series-is-50-complete/|website=Only Kollywood.com}}</ref> ''ಮಿರಲ್'' (2022) ಬೊಕ್ಕ ''ಲವ್'' (2023) ಡ್ ಭರತ್ ನ ಬುಡೆದಿ ಆದ್ ನಟನೆ ಮಲ್ತೆರ್. <ref>{{Cite news|url=https://indiaglitz.com/miral-review-tamil-movie-29638|title=Miral Movie Review|work=Indiaglitz|access-date=2022-11-11}}{{Dead link|date=April 2026 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> <ref>{{Cite news|url=https://www.cinemaexpress.com/tamil/review/2023/Jul/28/love-movie-review-overcooked-plot-insipid-execution-brings-down-a-film-with-promise-46049.html|title=Love Movie Review: Overcooked plot, insipid execution brings down a film with promise|work=Cinema Express|access-date=2023-07-28}}</ref> ದುಂಬುಗು, ವಾಣಿ ಭೋಜನ್ ಮಹಿಳಾ ನಾಯಕಿಯಾದ್ ನಾಟಕ ಚಿತ್ರ, ''ಅಂಜಮೈ'' (೨೦೨೪) ಡ್ ನಟನೆ ಮಲ್ತೆರ್. <ref>{{Cite news|url=https://www.cinemaexpress.com/tamil/news/2024/May/24/vidaarths-next-with-vani-bhojan-titled-anjaamai|title=Vidaarth's next with Vani Bhojan titled Anjaamai|work=Cinema Express|access-date=2024-05-24}}</ref> ಸುಂದರ್ ಸಿ ನ ''ಗ್ಯಾಂಗರ್ಸ್'' (೨೦೨೫) ಡ್ ಆಕ್ಷನ್ ಕಾಮಿಡಿ ಚಿತ್ರೊಡು ಆರ್ ನಟನೆ ಮಲ್ತೆರ್. <ref>{{Cite news|url=https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/sundar-c-and-vadivelus-reunion-gangsters-to-release-in-april/articleshow/118701208.cms|title=Sundar C and Vadivelu's reunion 'Gangsters' to release in April|work=The Times of India|access-date=2025-03-04}}</ref> == ಚಿತ್ರಕಲೆ == === ಸಿನಿಮಾಲು === * ''ಗಮನಿಸಿ: ಬೇತೆ ರೀತಿಡ್ ಗಮನಿಸಂದಿನ ಮುಟ್ಟ ಮಾತಾ ಸಿನಿಮಾಲು ತಮಿಳು ಭಾಷೆಡ್ ಉಂಡು.'' {| class="wikitable plainrowheaders sortable" |+ಸಿನಿಮಾ ಬೊಕ್ಕ ಪಾತ್ರೊಲೆನ ಪಟ್ಟಿ ! scope="col" | ವರ್ಷ ! scope="col" | ಪುದರ್ ! scope="col" | ಪಾತ್ರ(ಲು) ! class="unsortable" scope="col" | ಟಿಪ್ಪಣಿಲು ! class="unsortable" scope="col" | |- | ೨೦೧೦ ! scope="row" | ''ಒರ್ರ್ ಎರಾವು'' | ಡೈಸಿ | ಸುರುತ ಚಿತ್ರ; ಹೆವಂತಿಕಾ ಪಂಡ್ದ್ ಕ್ರೆಡಿಟ್ ಕೊರ್ತೆರ್ | style="text-align:center;" | <ref>{{Cite web|url=https://www.shankarbros.com/orr-eravuu.html|title=Orr Eravuu}}</ref> |- | ೨೦೧೨ ! scope="row" | ''ಅಡಿಗರಂ ೭೯ ೧.'' | ಪೂಜೆ | | style="text-align:center;" | <ref name="D">{{Cite web|date=25 November 2009|title=NFDC returns with Film Bazaar India 2009|url=https://businessofcinema.com/bollywood-news/nfdc-returns-with-film-bazaar-india-2009/29976|accessdate=26 September 2020}}</ref> |- | ೨೦೧೯ ! scope="row" | ''ಮೀಕು ಮಾತೃಮೆ ಚೆಪ್ತ'' | ಸ್ಟೆಫಿ | [[ತೆಲುಗು ಬಾಸೆ|ತೆಲುಗು]] ಚಿತ್ರ | style="text-align:center;" | <ref>{{Cite news|url=https://www.thehindu.com/entertainment/movies/meeku-maatrame-cheptha-movie-review-entertaining-but-only-in-parts/article29854469.ece|title=Vani Bhojan's 'Meeku Maatrame Cheptha' movie review: Entertaining, but only in parts|last=Chowdhary|first=Y. Sunita|date=1 November 2019|work=The Hindu|access-date=4 January 2021|language=en-IN|issn=0971-751X}}</ref> |- | rowspan="2" | ೨೦೨೦ ! scope="row" | ''ಓ ಎನ್ನ ಕಡವುಲೆ'' | ಮೀರಾ | | style="text-align:center;" | <ref>{{Cite news|url=https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/ashok-selvan-ritika-come-together-for-fun-romcom/articleshow/71097443.cms|title=Ashok Selvan & Ritika come together for fun romcom|last=Cr|first=Sharanya|work=The Times of India|access-date=15 October 2019|archive-url=https://web.archive.org/web/20191011084849/https://timesofindia.indiatimes.com/entertainment/tamil/movies/news/ashok-selvan-ritika-come-together-for-fun-romcom/articleshow/71097443.cms|archive-date=11 October 2019|language=en}}</ref> |- ! scope="row" | ''ಲಾಕ್ ಅಪ್ ಮಲ್ಪುಲೆ'' | ಮೀನಾ | | style="text-align:center;" | <ref>{{Cite web|url=https://timesofindia.indiatimes.com/entertainment/tamil/movie-reviews/lock-up/movie-review/77541075.cms|title=Lockup}}</ref> |- | rowspan="2" | ೨೦೨೧ ! scope="row" | ''ಮಲೇಷ್ಯಾ ಡ್ದ್ ಅಮ್ನೇಷಿಯಾ ಮುಟ್ಟ'' | ಸುಜಾತಾ (ಅರುಕಾಣಿ) | | style="text-align:center;" | <ref>{{Cite web|date=6 May 2021|title=8 gripping new movies and shows on Zee5 releasing this May 2021 that you shouldn't miss|url=https://www.gqindia.com/binge-watch/collection/8-gripping-new-movies-shows-zee5-releasing-may-2021-cant-miss/|website=GQ India}}</ref> |- ! scope="row" | ''ರಾಮೆ ಆಂಡಲಂ ರಾವಣೆ ಆಂಡಲಂ'' | ನರ್ಮಧ ಪೆರಿಯಸಾಮಿ | | style="text-align:center;" | <ref>{{Cite web|date=5 August 2021|title=Suriya's Jai Bhim, Udanpirappe, Raame Aandalum Raavane Aandalum and Oh My doG to release on Amazon Prime|url=https://indianexpress.com/article/entertainment/tamil/suriya-jai-bhim-udanpirappe-raame-aandalum-raavane-aandalum-and-oh-my-dog-to-release-on-amazon-prime-7439499/lite/|accessdate=5 August 2021|website=[[The Indian Express]]}}</ref> |- | rowspan="2" | ೨೦೨೨ ! scope="row" | ''ಮಹಾನ್'' | ಮಂಗೈ | ದೆತ್ತ್ ಪಾಡ್ದಿನ ದೃಶ್ಯೊಲು | <ref name=":0"/> |- ! scope="row" | ''ಮಿರಲ್'' | ರಾಮ | | style="text-align:center;" | <ref>{{Cite web|date=1 June 2022|title=Bharath-Vani Bhojan film titled Miral|url=https://www.cinemaexpress.com/tamil/news/2022/jun/01/bharath-vani-bhojan-film-titled-miral-31904.html|website=[[Cinema Express]]}}</ref> |- | rowspan="2" | ೨೦೨೩ ! scope="row" | ''ಪಾಯುಂ ಒಲಿ ನೀ ಯೆನಕ್ಕು'' | ಉತ್ರಾ | | style="text-align:center;" | <ref>{{Cite web|title=Shooting of Paayum Oli Nee Yenakku wrapped &#124; Cinemaexpress|url=https://m.cinemaexpress.com/stories/news/2021/apr/05/shooting-of-paayum-oli-nee-yenakku-wrapped-23787.amp|website=[[Cinema Express]]|accessdate=2026-03-28|archivedate=2021-06-02|archive-url=https://web.archive.org/web/20210602212344/https://m.cinemaexpress.com/stories/news/2021/apr/05/shooting-of-paayum-oli-nee-yenakku-wrapped-23787.amp|url-status=dead}}</ref> |- ! scope="row" | ''ಪ್ರೀತಿ'' | ದಿವ್ಯ | | style="text-align:center;" | <ref>{{Cite web|url=https://timesofindia.indiatimes.com/entertainment/tamil/movie-reviews/love/movie-review/102164360.cms|title=Love}}</ref> |- | rowspan="1" | ೨೦೨೪ ! scope="row" | ''ಅಂಜಮಾಯಿ'' |<nowiki> ಸರಸ್ವತಿ ಸರ್ಕಾರ |</nowiki> | | style="text-align:center;" | <ref>{{Cite news|url=https://www.ottplay.com/news/anjaamai-trailer-starring-vidaarth-is-here-/8b66435fcf261|title=Anjaamai trailer: Watch Vidaarth struggle to provide education for his son amid the NEET controversy|date=28 May 2024|work=[[OTT Play]]|access-date=28 May 2024|archive-url=https://web.archive.org/web/20240528164806/https://www.ottplay.com/news/anjaamai-trailer-starring-vidaarth-is-here-/8b66435fcf261|archive-date=28 May 2024|language=en}}</ref> |- | rowspan="1" | ೨೦೨೫ ! scope="row" | ''ಗಂಗರ್ಸ್'' | ಮಾಧವಿ | | style="text-align:center;" | <ref>{{Cite news|url=https://www.thehindu.com/entertainment/movies/gangers-movie-review-vadivelu-almost-saves-sundar-cs-low-stakes-heist-comedy/article69486723.ece|title='Gangers' movie review: Vadivelu almost saves Sundar C's low-stakes heist comedy|last=Rajendran|first=Gopinath|date=2025-04-24|work=The Hindu|access-date=2025-05-28|language=en-IN|issn=0971-751X}}</ref> |} === ಟೀವಿಡ್ === {| class="wikitable plainrowheaders" ! scope="col" |ವರ್ಷ ! scope="col" | ಪುದರ್ ! scope="col" | ಪಾತ್ರ ! scope="col" | ನೆಟ್ವರ್ಕ್ ! class="unsortable" scope="col" | ಟಿಪ್ಪಣಿಲು ! class="unsortable" scope="col" | Ref. |- | rowspan="2" | ೨೦೧೨ ! scope="row" | ''ಆಹಾ'' | ಶ್ರುತಿ | ಸ್ಟಾರ್ ವಿಜಯ್ | | style="text-align:center;" | <ref>{{Cite news|url=https://english.newstracklive.com/ampnews/vani-bhojan-sexy-photo-video-south-tv-film-actress-vani-bhojan-hot-sexy-bold-sc90-nu-1056478-1.html|title=Vani Bhojan shared its glamorous photos, photos goes viral|work=English News Track Live|access-date=1 June 2021}}</ref> |- ! scope="row" | ''ಮಾಯ'' | ಮಾಯ | ಜಯ ಟಿ.ವಿ | | style="text-align:center;" | <ref>{{Cite web|url=https://nettv4u.com/about/tamil/tv-serials/maya|title=Maya}}</ref> |- | ೨೦೧೩– ೨೦೧೮ ! scope="row" | ''<nowiki>ದೈವಮಗಲ್ ||</nowiki>'' | ಸತ್ಯ ಪ್ರಿಯ "ಸತ್ಯ" ಪ್ರಕಾಶ್ | ಸನ್ ಟಿವಿ | | style="text-align:center;" | <ref>{{Cite news|url=https://timesofindia.indiatimes.com/tv/news/tamil/deivamagal-comes-to-an-end/articleshow/63080540.cms|title=Deivamagal comes to an end|date=26 February 2018|work=The Times of India}}</ref> |- | ೨೦೧೫-೨೦೧೭ ! scope="row" | ''<nowiki>ಲಕ್ಷ್ಮೀ ವಂಧಚು|</nowiki>'' | ನಂಧಿನಿ / ಲಕ್ಷ್ಮೀ ವೇತ್ರಿವೆಲ್ & ಝಾನ್ಸಿ | ಝೀ ತಮಿಳು | | style="text-align:center;" | <ref name="I">{{Cite web|date=27 June 2015|title=Lakshmi Vanthachu is the new mega serial in town|url=https://timesofindia.indiatimes.com/tv/news/tamil/Lakshmi-Vanthachu-is-the-new-mega-serial-in-town/articleshow/47829021.cms|accessdate=29 August 2019|website=The Times of India}}</ref> |- | ೨೦೧೭ ! scope="row" | ''ಪ್ರೇಮ'' | ಪ್ರಿಯಾಂಕಾ / ಪ್ರೇಮಾ | ಇಟಿವಿ ತೆಲುಗು | [[ತೆಲುಗು ಬಾಸೆ|ತೆಲುಗು]] ಟೆಲಿಫಿಲ್ಮ್ | style="text-align:center;" | <ref name="E"/> |- |} === ವೆಬ್ ಸರಣಿ === {| class="wikitable plainrowheaders" ! scope="col" |ವರ್ಷ ! scope="col" | ಪುದರ್ ! scope="col" | ಪಾತ್ರ ! scope="col" | ಭಾಷೆ ! scope="col" | ನೆಟ್ವರ್ಕ್ ! class="unsortable" scope="col" | ಟಿಪ್ಪಣಿಲು ! class="unsortable" scope="col" | Ref. |- | ೨೦೨೦ ! scope="row" | ''ಟ್ರಿಪಲ್ಸ್'' | ಮೀರಾ | rowspan="4" | ತಮಿಳು | ಡಿಸ್ನಿ+ ಹಾಟ್ಸ್ಟಾರ್ | ವೆಬ್ ಡೆಬ್ಯೂಟ್ | style="text-align:center;" | <ref>{{Cite news|url=https://www.thehindu.com/entertainment/movies/karthik-subbaraj-triples-is-a-tribute-to-crazy-mohan/article33247915.ece|title=Karthik Subbaraj: 'Triples' is a tribute to Crazy Mohan|last=Kumar|first=Pradeep|date=4 December 2020|work=The Hindu|access-date=4 December 2020|language=en-IN|issn=0971-751X}}</ref> <ref>{{Cite news|url=https://timesofindia.indiatimes.com/videos/entertainment/web-series/mx-play/tamil/triples-trailer-video-vani-bhojan-jai-and-vivek-prasanna-starrer-triples-official-trailer-video/videoshow/79512241.cms|title='Triples' Trailer Video: Vani Bhojan, Jai and Vivek Prasanna starrer 'Triples' Official Trailer Video|work=The Times of India}}</ref> |- | ೨೦೨೨ ! scope="row" | ''ತಮಿಳು ರಾಕರ್ಜ್'' | ಸಂಧ್ಯಾ ವೇಣುಗೋಪಾಲ್ | ಸೋನಿಲಿವ್ | | style="text-align:center;" | <ref>{{Cite web|date=15 November 2021|title=Vani Bhojan and Aishwarya pair up with Arun Vijay in Web Series and Director by Arivazhagan|url=https://www.dtnext.in/amp/Lifestyle/LifeStyleTopNews/2021/11/16025741/1329044/Aishwarya-Lekshmi-Vani-Bhojan-play-female-lead-in-.vpf|archiveurl=https://web.archive.org/web/20211117104435/https://www.dtnext.in/amp/Lifestyle/LifeStyleTopNews/2021/11/16025741/1329044/Aishwarya-Lekshmi-Vani-Bhojan-play-female-lead-in-.vpf|archivedate=17 November 2021|website=DTNext.in}}</ref> |- | ೨೦೨೩ ! scope="row" | ''ಸೆಂಗಳಂ'' |<nowiki> ಸೂರ್ಯಕಾಲ ರಾಜಮಣಿಕಂ |</nowiki> | ZEE5 | | style="text-align:center;" | <ref>{{Cite web|date=19 March 2023|title=Sengalam Zee5 Webseries|url=https://thenewscrunch.com/sengalam-zee5-webseries-cast-crew-release-date-and-how-to-watch-online/45014/|website=thenewscrunch.com|language=en}}</ref> <ref>{{Cite web|date=18 March 2023|title=செங்களம் எனும் இணையத் தொடர்|url=https://www.virakesari.lk/article/150847|website=virakesari.lk|language=ta}}</ref> |- | ೨೦೨೪ ! scope="row" | ''ಚಟ್ನಿ ಸಾಂಬಾರ್'' | ಸೋಫಿ | ಡಿಸ್ನಿ+ ಹಾಟ್ಸ್ಟಾರ್ | | style="text-align:center;" | <ref>{{Cite web|url=https://www.indiatoday.in/television/web-series/story/chutney-sambar-review-director-radha-mohan-show-passable-entertainer-2573270-2024-07-29|title='Chutney Sambar' Review: Director Radha Mohan's show is a passable entertainer}}</ref> |} === ಟೆಲಿವಿಷನ್ === {| class="wikitable" !ವರ್ಷ ! ಬಹುಮಾನ ! ವಿಭಾಗ ! ಸರಣಿ ! ಫಲಿತ ! |- | ೨೦೧೩ |<nowiki> ತಮಿಳುನಾಡು ಟೆಲಿವಿಷನ್ ಪ್ರಶಸ್ತಿ ಪ್ರದಾನ |</nowiki> | ಅತ್ಯುತ್ತಮ ಸುರುತ ನಟಿ | rowspan="14" | ''<nowiki>ದೈವಮಗಲ್ ||</nowiki>'' | {{Won}} | |- | rowspan="4" | ೨೦೧೪ | rowspan="7" | ಸೂರ್ಯ ಕುಡುಂಬಂ ವಿರುತುಗಲ್ | ಎಡ್ಡೆ ನಟಿ | {{Nom}} | |- |<nowiki> ದೇವತಾಯಿಗಲ್ | </nowiki>| {{won}} | |- | ಎಡ್ಡೆ ನಟಿ | {{Nom}} | |- | ಅತ್ಯುತ್ತಮ ಸುರುತ ನಟಿ | {{Nom}} | |- | rowspan="8" | ೨೦೧೮ | ಎಡ್ಡೆ ನಟಿ| {{won}} | |- | ಅತ್ಯುತ್ತಮ ಜನಪ್ರಿಯ ಜೋಡಿ| {{won}} | <ref>{{Cite web|title=Sun Kudumbam Awards 2018 Winners – Sun Kudumbam Virudhugal|url=https://www.indiantvinfo.com/sun-kudumbam-awards-2018/}}</ref> |- | ಎಡ್ಡೆ ಜೋಡಿ | {{Nom}} | |- |<nowiki> ವಿಕಾತನ ಪ್ರಶಸ್ತಿ ಪ್ರದಾನ |</nowiki> | ಎಡ್ಡೆ ನಟಿ | {{Won}} | |- | ವಿಕತನ್ ನಂಬಿಕಾಯಿ ವಿರುತುಗಲ್ | ಎಡ್ಡೆ ನಟಿ| {{Won}} | <ref>{{Cite web|last=நிருபர்|first=நமது|title=ஆனந்த விகடன் நம்பிக்கை விருதுகள் 2018|url=https://www.vikatan.com/news/miscellaneous/146652-ananda-vikatan-nambikkai-awards|website=vikatan.com/}}</ref> |- |<nowiki> ಅವಲ್ ವಿರುತುಗಲ್|</nowiki> | ಅತ್ಯುತ್ತಮ ಸಣ್ಣ ಪರದೆದ ನಟಿ|{{Won}} | <ref>{{Cite web|title=Sun TV Aval Viruthugal 2018 Winners Performance Full Show 16-12-2018|url=http://www.indwiki.co.in/sun-tv-aval-viruthugal-2018-winners-performance-full-show-16-12-2018/|accessdate=2026-03-28|archivedate=2021-05-14|archive-url=https://web.archive.org/web/20210514132106/http://www.indwiki.co.in/sun-tv-aval-viruthugal-2018-winners-performance-full-show-16-12-2018/|url-status=dead}}</ref> |- |<nowiki> ಗಳತ್ತ ನಕ್ಷತ್ರ ಪ್ರಶಸ್ತಿ ಪ್ರದಾನ |</nowiki> | ಎಡ್ಡೆ ನಟಿ| {{Won}} | <ref>{{Cite web|title=Galatta Nakshatra Awards 2018 in Zee Tamil 28th, 29th April 2018 Winners Celebrities Performance|url=http://www.indwiki.co.in/galatta-nakshatra-awards-2018-in-zee-tamil-28th-29th-april-2018-winners-celebrities-performance/|accessdate=14 May 2021|archivedate=14 May 2021|archiveurl=https://web.archive.org/web/20210514131815/http://www.indwiki.co.in/galatta-nakshatra-awards-2018-in-zee-tamil-28th-29th-april-2018-winners-celebrities-performance/}}</ref> |- |} === ಸಿನಿಮಾಲು === == ಅಂಚನೆ ತೂಲೆ == * ಭಾರತೀಯ ಚಿತ್ರ ನಟಿಯರ ಪಟ್ಟಿ|| * ತಮಿಳು ಚಿತ್ರ ನಟಿಯರ ಪಟ್ಟಿ|| * ಭಾರತೀಯ ಟೆಲಿವಿಷನ್ ನಟಿಯರ ಪಟ್ಟಿ|| == ಟಿಪ್ಪಣಿಲು == == ಉಲ್ಲೇಖೊಲು == [[ವರ್ಗೊ:ಸ್ತ್ರೀವಾದೊ ಬುಕ್ಕೊ ಜಾನಪದೊ 2026]] 58v3oh600srywor8w0sltg8js5g1285 ಕರಿನೆಕ್ಕಿ 0 27211 362731 361372 2026-07-13T00:14:38Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362731 wikitext text/x-wiki {{Speciesbox | name = ''ಕರಿನೆಕ್ಕಿ'' | image = Justicia gendarussa 07.JPG | image_alt = Leaves and flowers | taxon = Justicia gendarussa | authority = [[Nicolaas Laurens Burman|Burm.f.]] | synonyms= *''Adhatoda subserrata'' {{small|Nees (1847)}} *''Dianthera subserrata'' {{small|Blanco (1837)}} *''Dicliptera rheedei'' {{small|Kostel. (1834)}} *''Ecbolium gendarussa'' {{small|(Burm.f.) Kuntze (1891)}} *''Ecbolium gendarussa'' var. ''angustifolium'' {{small|Kuntze (1891)}} *''Ecbolium subserratum'' {{small|Kuntze (1891)}} *''Gendarussa vulgaris'' <small>[[Christian Gottfried Daniel Nees von Esenbeck|Nees]] (1832)</small> *''Justicia dahona'' {{small|Buch.-Ham. ex Wall. (1830)}} *''Justicia gandarussa'' {{small|L.f. (1782), orth. var.}} *''Justicia gendarussa'' var. ''angustifolia'' {{small|(Kuntze) Hochr. (1934)}} *''Justicia salicina'' {{small|Vahl ex Nees (1847)}} | synonyms_ref = <ref name = powo>[https://powo.science.kew.org/taxon/urn:lsid:ipni.org:names:50766-1 ''Justicia gendarussa'' Burm.f.] ''[[Plants of the World Online]]''. Retrieved 13 March 2024.</ref> }} [[File:Justicia gendarussa.jpg|thumb|ದೈ]] '''ಕರಿನೆಕ್ಕಿ'''ಉಂದು ಒಂಜಿ ಮರ್ದ್‍ದ ದೈ.ಜಸ್ಟಿಸಿಯಾ ಗೆಂಡರುಸ್ಸಾ ಪನ್ಪಿನ ವೈಜ್ಞಾನಿಕ ಪುದರ್ ಉಂಡು.ಅಕಾಂತೇಸಿ ಕುಟುಂಬ. ==ಅವಾಸ== ಆಗ್ನೇಯ [[ಏಷ್ಯಾ]],[[ಭಾರತ]] ಉಪಖಂಡ,[[ಮಲೇಷ್ಯ|ಮಲೇಷಿಯಾ]],ಸುಮಾತ್ರಾ ಮೂಲು ಸ್ಥಳೀಯವಾತುಂಡು. ==ಸ್ಥಳೀಯ ಪುದರ್== [[ತಮಿಳು ಬಾಸೆ|ತಮಿಳು]]-ಕರುನೊಚ್ಚಿ [[ತೆಲುಗು ಬಾಸೆ|ತೆಲುಗು]]-ನಲ್ಲನೊಚ್ಚಿ, ತುಳು-ಕರಿನೆಕ್ಕಿ, [[ಮಲಯಾಳಂ ಬಾಸೆ|ಮಲಯಾಳಂ]]-ಕರಿನೊಚ್ಚಿಲ್,ಕನ್ನಡ-ಕರಿನೆಕ್ಕಿಗಿಡ, [[ಹಿಂದಿ ಬಾಸೆ|ಹಿಂದಿ]]-ಕಾಲಾಭಾಶಿಂಬ, [[ಸಂಸ್ಕೃತ ಬಾಸೆ|ಸಂಸ್ಕೃತ]]-ಕೃಷ್ಣನಿರ್ಗುಂಡಿ <ref>{{Cite web |title=ಕರಿನೆಕ್ಕಿಗಿಡ|url=https://dn710701.ca.archive.org/0/items/FiveHundredIndianPlants/FiveHundredIndianPlants.pdf }}</ref> ==ಲಕ್ಷಣಲು== ಜೆ. ಜೆಂಡಾರುಸ್ಸಾ ಪಂಡ ಒಂಜಿ ಉಂತುನ, ಶಾಖೆದ ಪೊದೆ. ಉಂದು ಅಕ್ಯಾಂಥಾಸಿ ಕುಟುಂಬೊಗು ಸೇರ್ದಿನವು. ಉಂದು ಒಂಜಿ ದ್ವಿಕೋಟಿಲೆಡೋನಸ್ ಸಸ್ಯ ಆದುಪ್ಪುನೆರ್ದಾತ್ರ 1.5 ಮೀ ಎತ್ತರೊಗು ಏರುಂಡು. ಇಂದೆತ ಇರೆಕುಲು ಲಾನ್ಸಿಯೋಲೇಟ್ ಉಪ್ಪುಂಡು, ಉದ್ದ 4-14 ಸೆಂ.ಮೀ ಬೊಕ್ಕ ಅಗಲ 1-2.5 ಸೆಂ.ಮೀ. ಇರೆಕುಲೆನ ಬಣ್ಣ ಬೊಲ್ದು, ಪಚ್ಚೆ ಅತ್ತ್ಂಡ ಬೂದು. ಬೊಕ್ಕ ರಡ್ಡ್ ಬದಿಟ್ಲಾ ಎಲ್ಯ ರೋಮ ಉಪ್ಪುಂಡು.<ref>{{Cite journal|language=en|doi=10.1088/1755-1315/794/1/012137|s2cid=236782236|title=A review on the bioactivities of Justicia gendarussa |year=2021 |last1=Chandra |first1=Shierly |last2=Lo |first2=Diana |journal=IOP Conference Series: Earth and Environmental Science |volume=794 |issue=1 |article-number=012137 |bibcode=2021E&ES..794a2137C |doi-access=free }}</ref> ರುಚಿ ಕೈಪೆ, ಬೊಕ್ಕ ಉಷ್ಣಜನಕವಾಯಿನವು. ಎಲ್ಯ ಎಲ್ಯ ಪೂಕುಲು ಶಾಖೆಲೆನ ಕೊನೊಟು ಅತ್ತಂಡ ಇರೆತ ಅಕ್ಷೊಲೆಡ್ 4-12 ಸೆಂ.ಮೀ. ಉದ್ದದ ಮುಳ್ಳುಲೆನ ರೂಪೊಡು ಬುಲೆಪುಂಡು. ಪುಷ್ಪೊಲೆನ ಬಣ್ಣ ಬೊಲ್ದು ಅತ್ತ್ಂಡ ಗುಲಾಬಿ ಬಣ್ಣೊಡು ನೇರಳೆ ಬಣ್ಣದ ಕಲೆಕುಲು ಉಪ್ಪುಂಡು. ಪುಷ್ಪೊಲು ಹರ್ಮಫ್ರೋಡೈಟ್ ಬೊಕ್ಕ ತೊಗಟೆಗ್ ಕಪ್ಪು ನೇರಳೆ ಬಣ್ಣ ಉಪ್ಪುಂಡು.<ref>{{Cite book|last1=Dymock|first1=William|url=https://www.biodiversitylibrary.org/bibliography/8696|title=Pharmacographia indica :A history of the principal drugs of vegetable origin, met with in British India|last2=Warden|first2=C. J. H.|last3=Hooper|first3=David|date=1890|publisher=K. Paul, Trench, Trübner & co., ld; [etc. etc.]|location=London}}</ref> ಜೆ. ಜೆಂಡಾರುಸ್ಸಾ ದ ಕಾಯಿ ಸುಮಾರ್ 1.2 ಸೆಂ.ಮೀ. ಉದ್ದ ಬೊಕ್ಕ ಮೃದುವಾದುಂಡು. ಈ ಸಸ್ಯೊಡು ಫ್ಲೇವೊನಾಯ್ಡ್ಸ್, ಆಲ್ಕಲಾಯ್ಡ್ಸ್, ಸ್ಟೀರಾಯ್ಡ್ಸ್ ಬೊಕ್ಕ ಫಿನಾಲಿಕ್ ಸಂಯುಕ್ತೊಲೆನಂಚಿನ ಜೀವಸಕ್ರಿಯ ಸಂಯುಕ್ತೊಲೆನ ವ್ಯಾಪಕ ಶ್ರೇಣಿ ಉಂಡು. ==ಉಪಯೋಗಲು== ಇರೆಕುಲು ಪರ ವಾತಗ್, ಇರೆತ [[ಕಷಾಯ]] [[ಜರೊ|ಜ್ವರ]]ಕ್ಕ್ ಮರ್ದ್.ಜೊಕುಲೆನ ಆಸ್ತಮಾ, [[ಸಂಧಿವಾತ]] ಬೊಕ್ಕ [[ಬಂಜಿಬೇನೆ]] ಪ್ರಕರಣಳೆಡ್ ಉಪಯೋಗ. ಇಂದೆನ್ ಸಾಂಪ್ರದಾಯಿಕವಾದ್ [[ಪಪುವಾ]]ದ ಕೆಲವು ಬುಡಕಟ್ಟು ಜನಾಂಗದಕುಲು ಪುರುಷರ್‍ನ ಗರ್ಭನಿರೋಧಕವಾದ್ ಬಳಸುವೆರ್.ಹಳ್ಳಿಡ್ ಉಮಿಲ್ ಗಿಡ್ಪರೆ ಇರೆತ ಪುಗೆ ಪಾಡುವೆರ್. == ಪಿದಾಯಿದ ಸಂಪರ್ಕೊಲು == *[https://web.archive.org/web/20211114161258/https://www.anbg.gov.au/cgi-bin/apni?taxon_id=273885 Australian Plant Names Index] {{Webarchive|url=https://web.archive.org/web/20211114161258/https://www.anbg.gov.au/cgi-bin/apni?taxon_id=273885 |date=2021-11-14 }} *[http://www.malecontraceptive.org/#!gendarussa/cbct Male Contraception Initiative article on gendarussa] ==ಉಲ್ಲೇಖಲು== [[ವರ್ಗೊ:ಮರ್ದ್‌ದ ದೈ]] [[ವರ್ಗೊ:ಸಸ್ಯೊಲು]] 29k20cxi6za5b1atov2c4rp8daemo8d ಹೆಬ್ರಿ 0 27405 362741 362280 2026-07-13T03:12:08Z InternetArchiveBot 4316 Rescuing 0 sources and tagging 1 as dead.) #IABot (v2.0.9.5 362741 wikitext text/x-wiki {{Infobox settlement | name = ಹೆಬ್ರಿ | native_name = | native_name_lang = | other_name = Hebberi | settlement_type = ಪಟ್ಟಣೊ | image_skyline = | image_alt = | image_caption = | pushpin_map = India Karnataka#India | pushpin_label_position = | pushpin_map_alt = | pushpin_map_caption = Location in Karnataka, India | coordinates = {{coord|13|28|N|74|59|E|display=inline,title}} | subdivision_type = Country | subdivision_name = {{flag|India}} | subdivision_type1 = [[States and territories of India|State]] | subdivision_name1 = [[Karnataka]] | established_title = <!-- Established --> | established_date = | named_for = | government_type = | governing_body = | unit_pref = Metric | area_footnotes = | area_rank = | area_total_km2 = | elevation_footnotes = | elevation_m = | population_total = 11,071<ref>{{cite news | url=http://www.thehindu.com/news/cities/Mangalore/proposal-to-upgrade-udupi-city-municipal-council/article6589763.ece | title=Proposal to upgrade Udupi City Municipal Council | newspaper=The Hindu | date=12 November 2014 | last1=Prabhu | first1=Ganesh | archive-date=3 December 2014 | access-date=2 August 2019 | archive-url=https://web.archive.org/web/20141203010815/http://www.thehindu.com/news/cities/Mangalore/proposal-to-upgrade-udupi-city-municipal-council/article6589763.ece | url-status=live }}</ref> | population_as_of = | population_rank = | population_density_km2 = auto | population_demonym = | population_footnotes = | demographics_type1 = Languages | demographics1_title1 = Local | demographics1_info1 = [[Tulu language|Tulu]], [[Kundagannada dialect|Kundagannada]] | timezone1 = [[Indian Standard Time|IST]] | utc_offset1 = +5:30 | postal_code_type = <!-- [[Postal Index Number|PIN]] --> 576112 | postal_code = | registration_plate = KA-20 | blank1_name_sec1 = Nearest city | blank1_info_sec1 = [[Udupi]] | blank2_name_sec1 = [[Lok Sabha]] constituency | blank2_info_sec1 = [[Udupi Chikmagalur (Lok Sabha constituency)]] | blank3_name_sec1 = MP | blank3_info_sec1 = [[Kota Srinivas Poojary]] | blank4_name_sec1 = [[Vidhana Sabha]] constituency | blank4_info_sec1 = [[Karkala]] | blank5_name_sec1 = | blank5_info_sec1 = | website = | footnotes = | official_name = | pushpin_image = | imagesize = | leader_name = [[V Sunil Kumar]] | leader_title1 = [[MLA]] | leader_party = [[BJP]] }} '''ಹೆಬ್ರಿ''' [[ಪಶ್ಚಿಮ ಘಟ್ಟ]]ದೊ ​​ಪಾದೊಡ್ ಉಪ್ಪುನ ಒಂಜಿ ಊರು ಬೊಕ್ಕ ತಾಲೂಕು ಕೇಂದ್ರ ಕಚೇರಿ. ಹೆಬ್ರಿ ತಾಲೂಕುನ್ ಕಾರ್ಕಳ ತಾಲೂಕುಡ್ದ್ ಪ್ರತ್ಯೇಕ ಆದಾಯ ತಾಲೂಕು ಆದ್ ಕ್ರಿ.ಶ. ೨೦೧೮ಡ್ ಬೇತೆ ಮಲ್ತೆರ್.<ref>{{Cite news|date=2018-02-18|title=Hebri taluk inaugurated|language=en-IN|work=The Hindu|url=https://www.thehindu.com/news/national/karnataka/hebri-taluk-inaugurated/article22787036.ece|access-date=2021-10-09|issn=0971-751X|archive-date=9 October 2021|archive-url=https://web.archive.org/web/20211009053217/https://www.thehindu.com/news/national/karnataka/hebri-taluk-inaugurated/article22787036.ece|url-status=live}}</ref> ==ಸ್ಥಳೊ== ಉಂದು [[ಕುಡ್ಲ]], [[ಬ್ರಹ್ಮಾವರ]], [[ಕಾರ್ಕಳ]], [[ಕುಂದಾಪುರ]], [[ಆಗುಂಬೆ]], [[ಶಿವಮೊಗ್ಗ ಜಿಲ್ಲೆ|ಶಿವಮೊಗ್ಗ]], [[ಉಡುಪಿ]]ಗ್ ಪೋಪಿನ ಸಾದಿಲೆನ ಮುಖ್ಯ ಕೇಂದ್ರ ಬಿಂದು.ಜನಸಂಖ್ಯೆ ೧೧೦೭೧. ==ವಿಶೇಷತೆ== ಈ ಪ್ರದೇಶದ ಕಾಡುಲೆಡ್ ವರ್ಸೊದ ಪೂರಾ ಮಸ್ತ್ ಬರ್ಸ ಬರ್ಪುಂಡು. [[ಸೋಮೇಶ್ವರ]] ವನ್ಯಜೀವಿ ಅಭಯಾರಣ್ಯ ಸುತ್ತಮುತ್ತ ಉಂಡು, ಉಂದು ಆಗುಂಬೆ ಬೊಕ್ಕ ಪಶ್ಚಿಮ ಘಟ್ಟ ಮುಟ್ಟದ ಇಡೀ ಮಾರ್ಗೊನು ಒಳಗೊಂಡುಂಡು. ಈ ಅಭಯಾರಣ್ಯೊಡು ಕಾಳಿಂಗ ಸರ್ಪ ಸೇರ್ದ್ ನಾಶದಂಚಿಡುಪ್ಪುನ ಪ್ರಾಣಿ ಜಾತಿಲು ಉಂಡು<ref>{{Cite web |last=George |date=2017-10-17 |title=Someshwara Wildlife Sanctuary Known for Venomous King Cobras |url=https://touristinindia.com/someshwara-wildlife-sanctuary/ |access-date=2022-07-27 |website=Tourist in India |language=en-US |archive-date=27 July 2022 |archive-url=https://web.archive.org/web/20220727152157/https://touristinindia.com/someshwara-wildlife-sanctuary/ |url-status=live }}</ref> .ಮುಲ್ಪದ ಬಾಸೆಲು ಮಸ್ತ್ ಪಾತೆರುನ ತುಳು ಬೊಕ್ಕ ಕುಂದಗನ್ನಡ.ಕೊಂಕಣಿ ಪಾತೆರ್ನಕುಲುಲಾ ಉಲ್ಲೆರ್. ==ದುಡ್ಡು-ಕಾಸ್== ಹೆಬ್ರಿದ ಆರ್ಥಿಕತೆ ಮುಖ್ಯವಾದ್ ಕೃಷಿನ್ ಅವಲಂಬಿಸಾಯಿನವು, ಉಂದೆಟ್ ಅರಿ (ಭತ್ತ), ಬಜ್ಜೆಇ, ತಾರಾಯಿ, ಬೊಕ್ಕ ಗೋಡಂಬಿ ಸೇರ್ದ್ ಉಂಡು. ಇತ್ತೆದ ಕಾಲೊಡು ಪಶ್ಚಿಮ ಘಟ್ಟದ ​​ತಳಭಾಗೊಡುಲಾ ರಬ್ಬರ್ ಬುಳೆಪುಂಡು. ಹೆಬ್ರಿಡ್ ಬೊಕ್ಕ ಸುತ್ತಮುತ್ತ ಗೋಡಂಬಿ, ತಾರಾಯಿ ಬೊಕ್ಕ ಅರಿನ್ ಸಂಸ್ಕರಣೆ ಮಲ್ಪುನ ಮಸ್ತ್ ಕಾರ್ಖಾನೆಲು ಉಂಡು. ಹೆಬ್ರಿಡ್ ಒಂಜಿ ಶಾಲೆ, ಕಾಲೇಜು<ref>{{cite web|url=https://www.gfgc.kar.nic.in/hebri|title=COLLEGE PHOTO|access-date=29 April 2023|archive-date=29 April 2023|archive-url=https://web.archive.org/web/20230429050452/https://www.gfgc.kar.nic.in/hebri|url-status=live}}</ref>, ಒಂಜಿ ಸಮುದಾಯ ಆರೋಗ್ಯ ಕೇಂದ್ರ (ಸಿಎಚ್ಸಿ)<ref>{{cite web|url=https://timesofindia.indiatimes.com/a-health-camp-will-be-held-at-bellare-primary-health-centre-and-hebri-community-health-centre-on-saturday-to-identify-and-help-bpl-beneficiaries-avail-medical-benefits-given-by-suvarna-arogya-suraksha-trust-under-the-department-of-health-and-family-welfare-/articleshow/30002358.cms|title=A health camp will be held at Bellare primary health centre ..|access-date=29 April 2023}}</ref>, ಪೊಲೀಸ್ ಠಾಣೆ<ref>{{cite web|url=https://udupipolice.karnataka.gov.in/3448/Hebri%20PS/en|title=Hebri PS|publisher=udupipolice.karnataka.gov.in|access-date=6 June 2026}}{{Dead link|date=July 2026 |bot=InternetArchiveBot |fix-attempted=yes }}</ref>, ಒಂಜಿ ಪೆಟ್ರೋಲ್ ಪಂಪ್ ಉಂಡು. ಉಡುಪಿ ಊರುನ್ ಆಗುಂಬೆಗ್ ಸಂಪರ್ಕ ಮಲ್ಪುನ ರಾಷ್ಟ್ರೀಯ ಹೆದ್ದಾರಿ 169ಎ ಹೆಬ್ರಿ ಮೂಲಕ ಪೋಪುಂಡು. ==ಉಲ್ಲೇಕೊಲು== [[ವರ್ಗೊ:ಊರುಲು]] [[ವರ್ಗೊ:ಉಡುಪಿ ಜಿಲ್ಲೆ]] 2bz2m55dmxqg3s68u6npsmy33m7ueru ಬ್ಯಾಂಕ್ ಆಫ್ ಮಹಾರಾಷ್ಟ್ರ 0 27477 362739 362642 2026-07-13T02:10:20Z InternetArchiveBot 4316 Rescuing 0 sources and tagging 2 as dead.) #IABot (v2.0.9.5 362739 wikitext text/x-wiki ಬ್ಯಾಂಕ್ ಆಫ್ ಮಹಾರಾಷ್ಟ್ರ ಭಾರತದ ಒಂಜಿ ಮಲ್ಲ ಸಾರ್ವಜನಿಕ ವಲಯದ ಬ್ಯಾಂಕ್ ಆದುಂಡು. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ಪುಣೆಡ್ ಉಂಡು. ಈ ಬ್ಯಾಂಕ್ ೧೯೩೫ನೇ ಇಸವಿಡ್ ಸ್ಥಾಪನೆ ಆಂಡ್ ಬೊಕ್ಕ ೧೯೬೯ನೇ ಇಸವಿಡ್ ಭಾರತ ಸರ್ಕಾರ ಇಂದೆನ್ ರಾಷ್ಟ್ರೀಕರಣ ಮಲ್ತ್ಂಡ್. ಜೂನ್ ೨೦೨೫ದ ಲೆಕ್ಕಾಚಾರದ ಪ್ರಕಾರ, ಈ ಬ್ಯಾಂಕ್‌ಗ್ ದೇಸೊರ್ಮೆ ಸುಮಾರ್ ೨,೬೪೧ ಶಾಖೆಲು ಉಲ್ಲ.<ref>{{cite web |title=Financial Results For Quarter Ended, 30th June 2025 |url=https://bankofmaharashtra.in/writereaddata/documentlibrary/0f76e3c6-256b-4306-bd61-3eae38ca1527.pdf |publisher=Bank of Maharashtra |access-date=15 August 2025 }}{{Dead link|date=July 2026 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳದ ಪ್ರಕಾರ, ಸಾರ್ವಜನಿಕ ವಲಯದ ಬ್ಯಾಂಕುಲೆಡ್ ಈ ಬ್ಯಾಂಕ್ ೮ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ೧೯೩೪ನೇ ಇಸವಿಡ್ ಪುಣೆಡ್ 'ಮರಾಠಾ ಚೇಂಬರ್ ಆಫ್ ಕಾಮರ್ಸ್' (MCC) ಸುರು ಆಂಡ್. ಅಯಿತ ಸ್ಥಾಪಕ ಕಾರ್ಯದರ್ಶಿ ಆಯಿನ ಶ್ರೀ ಎ.ಆರ್. ಭಟ್ ಬಾರೀ ದೂರದೃಷ್ಟಿ ಇತ್ತ್‌ನ ಮಾಮಲ್ಲ ನಾಯಕೆ ಆದಿತ್ತ್ಂಡ್. ಮರಾಠಾ ಚೇಂಬರ್ ಆಫ್ ಕಾಮರ್ಸ್ ಸುರು ಆಯಿನ ಕೆಲವು ತಿಂಗೊಳುಡು ಲೋಕಮಾನ್ಯ ತಿಲಕೆರೆನ ನೆನಪುಡು ಬುಡುಗಡೆ ಆಯಿನ 'ಕೇಸರಿ' ಪತ್ರಿಕೆದ ವಿಶೇಷ ಸಂಚಿಕೆಡ್ ಆ ಪ್ರದೇಶೊಡು ಇಪ್ಪುನ ಬ್ಯಾಂಕಿಂಗ್ ಸೇವೆಲೆನ ಬಗ್ಗೆ ಒಂಜಿ ವರದಿನ್ ಪ್ರಕಟ ಮಲ್ಪೆರೆ ಶ್ರೀ ಭಟ್ ಸುರು ಮಲ್ತೇರ್. ಅರೆನ ದೋಸ್ತಿ ಬೊಕ್ಕ ಸಹಕಾರ ಚಳವಳಿದ ಮಲ್ಲ ಮೇಧಾವಿ ಆಯಿನ ಶ್ರೀ ವಿ. ಪಿ. ವರ್ದೆ ಅರೆನ ಕೈಡ್ದ್ "ಮಹಾರಾಷ್ಟ್ರಗ್ ಒಂಜಿ ಪ್ರತ್ಯೇಕ ಬ್ಯಾಂಕ್ ಬೋಡು" ಪನ್ಪಿನ ವಿಷಯದ ಬಗ್ಗೆ ಒಂಜಿ ಬರವು ಬರೆಪಾಯೆರ್. ಈ ಲೇಖನಗ್ ಸುರುಟು ಜನಡ್ದ್ ಅಂಚಿನ ಮಲ್ಲ ಪ್ರತಿಕ್ರಿಯೆ ಬತ್ತಿಜಿಂಡಲಾ, ಶ್ರೀ ಎ.ಆರ್. ಭಟ್ ವ್ಯಾಪಾರ ಬೊಕ್ಕ ಕೈಗಾರಿಕಾ ರಂಗದ ಮಲ್ಲ ಜನಕುಲೆನ ಒಟ್ಟುಗು ಈ ವಿಷಯದ ಬಗ್ಗೆ ಪಾತೆರೊಂದು ಇತ್ತ್ಂಡ್. ಮಹರತ್ತಾ ಚೇಂಬರ್ ಬೊಕ್ಕ ಅಯಿತ ನಿರ್ದೇಶಕರು ಈ ವಿಷಯೊನು ಗಂಭೀರವಾದ್ ದೆತೊಂದು, ಫೆಬ್ರವರಿ ೧೯೩೫ಡ್ ಪುಣೆಡ್ ವ್ಯಾಪಾರ ಬೊಕ್ಕ ಕೈಗಾರಿಕಾ ಸಮ್ಮೇಳನಡ್ ಈ ಇಸಯ ಚರ್ಚೆಗ್ ಬತ್ತ್ಂಡ್. "ಮಹಾರಾಷ್ಟ್ರದ ವ್ಯಾಪಾರ ಬೊಕ್ಕ ಕೈಗಾರಿಕೆಲೆಗ್ ದುಡ್ಡುದ ಸೌಲಭ್ಯ ಕೊರಿಯೆರೆ ಒಂಜಿ ಜಾಯಿಂಟ್ ಸ್ಟಾಕ್ ಕಮರ್ಷಿಯಲ್ ಬ್ಯಾಂಕ್ (ವಾಣಿಜ್ಯ ಬ್ಯಾಂಕ್) ಸ್ಥಾಪನೆ ಮಲ್ಪುನು ಬಾರೀ ಅಗತ್ಯ ಉಂಡು. ಅಂಚಾದ್ ಮಹರತ್ತಾ ಚೇಂಬರ್ ಇಂದೆಕ್ ಬೋಡಾಯಿನ ಇಚಾರ ಮಲ್ತ್‌ದ್, ಬ್ಯಾಂಕ್ ಸುರು ಮಲ್ಪೆರೆ ಆವಶ್ಯಕ ಕ್ರಮ ದೆತೊನೊಡು. ಮಹಾರಾಷ್ಟ್ರದ ಮಾತಾ ವ್ಯಾಪಾರಸ್ಥರು ಈ ಪ್ರಯತ್ನೊಗು ಬೆರಿ ಸಹಾಯ ಕೊರೊಡು." ೨೦ನೇ ಶತಮಾನದ ಸುರುತ ದಶಕೊಡು ನಡತಿನ ಸ್ವದೇಶಿ ಚಳವಳಿ ಭಾರತದ ಜನಕುಲೆನ ಉಸ್ತುವಾರಿಡು ಮಹಾರಾಷ್ಟ್ರೊಡು ಮಸ್ತ್ ವಾಣಿಜ್ಯ ಬ್ಯಾಂಕುಲೆನ ಸ್ಥಾಪನೆಗ್ ಪ್ರೇರಣೆ ಕೊರ್ತುಂಡು. ಇಂದೆತ ಕೆಲಸೊಗಾದ್ MCC ಒಂಜಿ ಉಪ-ಸಮಿತಿನ್ ಉಂಡು ಮಲ್ತ್ಂಡ್. ಅಯಿಟು ಶ್ರೀ ವಿ.ಜಿ. ಕಾಳೆ, ಡಿ.ಕೆ. ಸಾಠೆ, ಎನ್.ಜಿ. ಪವಾರ್, ಜಿ.ಡಿ. ಆಪ್ಟೆ ಬೊಕ್ಕ ಎ.ಆರ್. ಭಟ್ ಇತ್ತೆರ್. ಈ ಸಮಿತಿದ ಸುರುತ ಕೂಟ ೧೯ ಮೇ ೧೯೩೫ ದಾನಿ ನಡತಿನ ಬೊಕ್ಕೊಂಜಿ ಮಲ್ಲ ಕೂಟೊಡು ನಿರ್ಧಾರೊಲೆನ್ ದೆತೊಂಡೆರ್: ಪ್ರಸ್ತಾಪಿತ ಬ್ಯಾಂಕ್‌ದ ಬೋರ್ಡ್‌ಡ್ ಗರಿಷ್ಠ ೧೧ ನಿರ್ದೇಶಕರು ಇಪ್ಪೊಡು, ಒಂಜಿ ಶೇರ್‌ದ ಬಿಲೆ ೫೦ ರೂಪಾಯಿ ಆವೊಡು, ಬೊಕ್ಕ ನಿರ್ದೇಶಕ ಆಯೆರೆ ಕನಿಷ್ಠ ೫೦೦ ಶೇರುಲು ಇಪ್ಪೊಡು ಪಂದ್ ತೀರ್ಮಾನ ಮಲ್ತೇರ್.<ref>{{cite web |title=bankofmaharashtra.bank.in |url=https://bankofmaharashtra.bank.in/the-begining |website=bankofmaharashtra.bank.in |publisher=BOM |access-date=10 July 2026}}</ref> ಅಂಚ ತೀರ್ಮಾನ ಆಯಿಬೊಕ್ಕ ಬ್ಯಾಂಕ್ ಆಫ್ ಮಹಾರಾಷ್ಟ್ರ ೧೬ ಸೆಪ್ಟೆಂಬರ್ ೧೯೩೫ ದಾನಿ ಬೊಂಬಾಯಿ ಪ್ರೆಸಿಡೆನ್ಸಿದ ಪೂನಾಡ್ (ಇತ್ತೆದ ಪುಣೆ, ಮಹಾರಾಷ್ಟ್ರ) ಸ್ಥಾಪನೆ ಆಂಡ್. ಭಾರತೊಡು ಸಹಕಾರಿ ಚಳವಳಿ ನಡತೊಂದು ಇತ್ತ್‌ನ ಆ ಸಮಯೊಡು, ಎಲ್ಯ ವ್ಯಾಪಾರಸ್ಥರೆಗ್ ಬೊಕ್ಕ ಉದ್ಯಮಿಲೆಗ್ ಬೆರಿ ಸಹಾಯ ಕೊರಿಯೆರೆ ಬೋಡಾದ್ 'ಮಹರತ್ತಾ ಚೇಂಬರ್ ಆಫ್ ಕಾಮರ್ಸ್' ಉಸ್ತುವಾರಿಡು ಈ ಬ್ಯಾಂಕ್ ಸುರು ಆಂಡ್.<ref name=":0"/><ref>{{cite web |title=Bank of Maharashtra: Rating reaffirmed; withdrawn for Rs. 600-crore Basel III tier II bonds |url=https://www.icra.in/Rationale/ShowRationaleReport?Id=136598 |publisher=ICRA |access-date=15 August 2025}}</ref> ಅಯಿಡ್ದ್ ಬೊಕ್ಕ, ೧೯೪೪ನೇ ಇಸವಿಡ್ ಈ ಬ್ಯಾಂಕ್ ಒಂಜಿ 'ಷೆಡ್ಯೂಲ್ಡ್ ಬ್ಯಾಂಕ್' ಆದ್ ನೋಂದಣಿ ಆಂಡ್. ೧೯೫೫ನೇ ಇಸವಿಡ್ 'ಬ್ಯಾಂಕಿಂಗ್ ಕಂಪೆನೀಸ್ ಆಕ್ಟ್' ಅಡಿಟ್ ಅಧಿಕೃತ ಬ್ಯಾಂಕಿಂಗ್ ಲೈಸೆನ್ಸ್ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕ್, ೧೯೫೮ನೇ ಇಸವಿಡ್ ಬಾಂಬೆ ಸ್ಟಾಕ್ ಎಕ್ಸ್ಚೇಂಜ್‌ಡ್ ದಾಖಲಾಂಡ್.<ref name=":0">{{cite web |title=Bank of Maharashtra - History and Growth |url=http://ir.unishivaji.ac.in:8080/jspui/bitstream/123456789/545/10/10_Chapter%204.pdf |publisher=Shivaji University |access-date=15 August 2025}}</ref> ==ಸ್ವಾದೀನೊ== ೧೯೬೧ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಮಹಾರಾಷ್ಟ್ರ ರಾಜ್ಯದ ಮೂಜಿ ಎಲ್ಯ ಬ್ಯಾಂಕುಲೆನ್- ಮಾಲ್ವಣ್‌ಡು ಇತ್ತ್‌ನ 'ಬ್ಯಾಂಕ್ ಆಫ್ ಕೊಂಕಣ್', ನಾಗಪುರಡು ಇತ್ತ್‌ನ 'ಬ್ಯಾಂಕ್ ಆಫ್ ನಾಗಪುರ' ಬೊಕ್ಕ ಪೂನಾಡ್ (ಇತ್ತೆದ ಪುಣೆ) ಇತ್ತ್‌ನ 'ಭಾರತ್ ಇಂಡಸ್ಟ್ರಿಯಲ್ ಬ್ಯಾಂಕ್- ಸ್ವಾಧೀನ ಮಲ್ತೊಂಡ್.<ref>{{cite web |title=Banks which have closed down or amalgamated or placed under liquidation during the period 1st March to 4th September 1961 |url=https://www.rsdebate.nic.in/bitstream/123456789/556125/2/IQ_35_06091961_U447_p3402_p3404.pdf |publisher=Rajya Sabha Debates |access-date=15 August 2025 }}{{Dead link|date=July 2026 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> == ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್ ಸುರು ಮಲ್ತಿನಿ== ಬ್ಯಾಂಕ್ ಆಫ್ ಮಹಾರಾಷ್ಟ್ರ, ಕೇಂದ್ರ ಬೊಕ್ಕ ರಾಜ್ಯ ಸರ್ಕಾರೊಲೆನ ಸೇರಿಕೆಡ್ ಮೂಜಿ ಪ್ರಾದೇಶಿಕ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕುಲೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |last1=Ray |first1=Partha |last2=Basu |first2=Sankarshan |title=Bank of Maharashtra: An Indian Small Public Sector Bank Unshackling itself from the baggage of the Past |url=https://www.nibmindia.org/documents/162/NIBM_Case_02_UsQmAix.pdf |publisher=National Institute of Bank Management |access-date=15 August 2025 |date=November 2022}}</ref> ಅವು ಒವ್ವು ಪಂಡ, ೧೯೭೬ಡ್ ನಾಂದೇಡ್‌ಡ್ ಸುರು ಆಯಿನ 'ಮರಾಠವಾಡ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್', ೧೯೮೧ಡ್ ಔರಂಗಾಬಾದ್‌ಡ್ ಸುರು ಆಯಿನ 'ಔರಂಗಾಬಾದ್-ಜಾಲ್ನಾ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್' ಬೊಕ್ಕ ೧೯೮೬ಡ್ ಥಾಣೆಡ್ ಸುರು ಆಯಿನ 'ಥಾಣೆ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್'. ೨೦೦೯ನೇ ಇಸವಿಡ್ ಈ ಪ್ರಾದೇಶಿಕ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕುಲೆನ್ ಒಟ್ಟು ಸೇರಾದ್ 'ಮಹಾರಾಷ್ಟ್ರ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್' ಪನ್ಪಿನ ಪೊಸ ಬ್ಯಾಂಕ್‌ನ್ ಮಲ್ತೇರ್.<ref>{{cite news |title=Bank of Maharashtra merges two RRBs |url=https://economictimes.indiatimes.com/bank-of-maharashtra-merges-two-rrbs/articleshow/2914903.cms |access-date=15 August 2025 |work=The Economic Times |date=31 March 2008}}</ref> ಅಯಿಡ್ದ್ ಬೊಕ್ಕ, ಭಾರತ ಸರ್ಕಾರದ "ಒಂಜಿ ರಾಜ್ಯ, ಒಂಜಿ ಪ್ರಾದೇಶಿಕ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್" (One State, One RRB) ನಿಯಮದ ಪ್ರಕಾರ, ಮೇ ೧, ೨೦೨೫ ದಾನಿ ಈ ಮಹಾರಾಷ್ಟ್ರ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್‌ನ್ 'ವಿದರ್ಭ ಕೊಂಕಣ್ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್'ದ ಒಟ್ಟುಗು ಸೇರಾದ್, ಇಡೀ ರಾಜ್ಯಗೇ ಒಂಜೇ ಪ್ರಾದೇಶಿಕ ಗ್ರಾಮೀಣ ಬ್ಯಾಂಕ್ ಆಪುಲೆಕ್ಕ ವಿಲೀನ ಮಲ್ತೇರ್.<ref>{{cite web | author1=Livemint | title='One state-one RRB' to be effective from May 1 after govt approves consolidation of 15 regional rural banks &#124; Mint | work=mint | date=8 April 2025 | url=https://www.livemint.com/economy/one-state-one-rrb-to-be-effective-from-may-1-after-govt-approves-consolidation-of-15-regional-rural-banks-11744118507326.html }}</ref> ==ಉಲ್ಲೇಕ== {{reflist}} [[ವರ್ಗೊ:ಬ್ಯಾಂಕುಲು]] [[ವರ್ಗೊ:ಭಾರತೊದ ಸಾರ್ವಜನಿಕ ರಂಗದ ಬ್ಯಾಂಕುಲು]] [[ವರ್ಗೊ:ತುಳು ವಿಕಿಪೀಡಿಯ 10ನೇ ವರ್ಸಾಂತ್ಯೊ]] 8tmg7teycrms29xtpib1t257hezww3i ಬಳಕೆದಾರೆ ಪಾತೆರ:Durga Prasad Nayakk 3 27481 362715 362652 2026-07-12T12:40:18Z Bharathesha Alasandemajalu 37 362715 wikitext text/x-wiki {{Template:Welcome|realName=|name=Durga Prasad Nayakk}} -- [[ಬಳಕೆದಾರೆ:ತುಳು ವಿಕಿಪೀಡಿಯ ಸಮುದಾಯೊ|ತುಳು ವಿಕಿಪೀಡಿಯ ಸಮುದಾಯೊ]] ([[ಬಳಕೆದಾರೆ ಪಾತೆರ:ತುಳು ವಿಕಿಪೀಡಿಯ ಸಮುದಾಯೊ|ಪಾತೆರ್ಲೆ]]) ೧೬:೨೪, ೧೦ ಜುಲಾಯಿ ೨೦೨೬ (IST) : ಮೋಕೆತ ಎಡ್ಡೆಪುಲು ತುಳು ವಿಕಿಪೀಡಿಯಗ್ ಎದ್ಕುನುವಾ -[[ಬಳಕೆದಾರೆ:Bharathesha Alasandemajalu|Bharathesha Alasandemajalu]] ([[ಬಳಕೆದಾರೆ ಪಾತೆರ:Bharathesha Alasandemajalu|ಪಾತೆರ್ಲೆ]]) ೧೮:೧೦, ೧೨ ಜುಲಾಯಿ ೨೦೨೬ (IST) f7vf67f86u7wc3r36dywntcbca7vfla ಗ್ರೆಗ್ ಅಬೊಟ್ 0 27486 362736 362671 2026-07-13T00:53:13Z InternetArchiveBot 4316 Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 362736 wikitext text/x-wiki {{Infobox officeholder | name = ಗ್ರೆಗ್ ಅಬೊಟ್ Greg Abbott | image = Greg Abbott at NASA 2024 (cropped).jpg | caption = | alt = ೨೦೨೪ಡ್ ಅಬ್ಬೊಟ್ | order = 48th | office = Governor of Texas | lieutenant = | term_start = ಜನವರಿ ೨೦, ೨೦೧೫ | term_end = | predecessor = | successor = | office1 = Chair of the [[Republican Governors Association]] | term_start1 = | term_end1 = | predecessor1 = ಪೀಟ್ ರಿಕೆಟ್ಸ್ | successor1 = ಡೌಗ್ ಡ್ಯೂಸಿ | office2 = 50th [[Texas Attorney General|Attorney General of Texas]] | governor2 = ಜನವರಿ ೨೦, ೨೦೧೫ | term_start2 = | term_end2 = | predecessor2 = ಜಾನ್ ಕಾರ್ನಿನ್ | successor2 = ಕೆನ್ ಪ್ಯಾಕ್ಸ್ಟನ್ | office3 = | appointer3 = | term_start3 = | term_end3 = | predecessor3 = [[Jack Hightower]] | successor3 = | birth_name = ಗ್ರೆಗರಿ ವೇನ್ ಅಬೊಟ್ | birth_date = {{birth date and age|1957|11|13}} | birth_place = ವಿಚಿಟಾ ಫಾಲ್ಸ್, ಟೆಕ್ಸಾಸ್ | party = ರಿಪಬ್ಲಿಕನ್ ಪಕ್ಷ | spouse = {{marriage|[[Cecilia Phalen]]|1981}} | children = 1 | education = [[University of Texas at Austin]] ([[Bachelor of Business Administration|BBA]])<br />[[Vanderbilt University]] ([[Juris Doctor|JD]]) | signature = Greg Abbott Signature.svg | website = {{URL|https://gov.texas.gov/|Office website}}<br/>{{URL|https://www.gregabbott.com/|Campaign website}} | module = }} ಗ್ರೆಗರಿ ವೇನ್ ಅಬೊಟ್ ('''Gregory Wayne Abbott''' /æbət/ ABB-ət; ಪುಟ್ಟು ೧೯೫೭) ಒರಿ ಅಮೆರಿಕದ ರಾಜಕಾರಣಿ, ವಕೀಲೆ, ಬೊಕ್ಕ ನ್ಯಾಯವಾದಿ, ೨೦೧೫ಡ್ದ್ ಟೆಕ್ಸಾಸ್ ದ ೪೮ನೇ ಗವರ್ನರ್ ಆದ್ ಸೇವೆ ಮಲ್ತೊಂದುಲ್ಲೆರ್. ರಿಪಬ್ಲಿಕನ್ ಪಕ್ಷದ ಸದಸ್ಯೆರಾದ್, 2002 ಡ್ದ್ 2015 ಮುಟ್ಟ ಟೆಕ್ಸಾಸ್ ದ 50ನೇ ಅಟಾರ್ನಿ ಜನರಲ್ ಆದ್ ಬೊಕ್ಕ 1996 ಡ್ದ್ 2001 ಮುಟ್ಟ ಟೆಕ್ಸಾಸ್ ಸುಪ್ರೀಂ ಕೋರ್ಟ್ ದ ನ್ಯಾಯಾಧೀಶೆರಾದ್ ಸೇವೆ ಮಲ್ತೆರ್. ಬೊಟ್ ನವೆಂಬರ್ ೧೩, ೧೯೫೭ಡ್ ವಿಚಿಟಾ ಫಾಲ್ಸ್, ಟೆಕ್ಸಾಸ್ ಡ್ ಪುಟ್ಟುವೆರ್, ಬೊಕ್ಕ ಆರ್ ಇಂಗ್ಲಿಷ್ ಮೂಲದಕುಲು. ಅರೆನ ಅಮ್ಮೆ, ಡೋರಿಸ್ ಲೆಕ್ರಿಸ್ಟಿಯಾ ಜ್ಯಾಕ್ಸ್ ಅಬೊಟ್, ಒರಿ ಗೃಹಿಣಿ ಆದಿತ್ತೆರ್ ಬೊಕ್ಕ ಅರೆನ ಅಪ್ಪೆ, ಕ್ಯಾಲ್ವಿನ್ ರೊಡ್ಜರ್ ಅಬೊಟ್, ಒರಿ ಸ್ಟಾಕ್ ಬ್ರೋಕರ್ ಬೊಕ್ಕ ವಿಮೆ ಏಜೆಂಟ್ ಆದಿತ್ತೆರ್. ಅರೆನ ಆರು ವರ್ಷ ಆನಗ, ಅಕುಲು ಲಾಂಗ್ವ್ಯೂಗ್ ಪೋಯೆರ್; ಆ ಕುಟುಂಬ ಆಜಿ ವರ್ಸೊಗು ಅಲ್ಪ ಜೀವನ ಮಲ್ತೆರ್. ಆರ್ 12 ವರ್ಷ ಆನಗ, ಅಬೊಟ್ ನ ಕುಟುಂಬ ಡಂಕನ್ವಿಲ್ಲೆಗ್ ಪೋಯೆರ್. ಪ್ರೌಢಶಾಲೆಡ್ ರಡ್ಡನೆ ವರ್ಷೊಡು, ಅರೆನ ಅಪ್ಪೆ ಹೃದಯಾಘಾತೊಡ್ದ್ ತೀರ್ ಪೋಯೆರ್; ಅರೆನ ಅಮ್ಮೆರ್ ಒಂಜಿ ರಿಯಲ್ ಎಸ್ಟೇಟ್ ಆಫೀಸ್ ಡ್ ಬೇಲೆ ಮಲ್ಪೆರೆ ಪೋಯೆರ್. ಅಬೊಟ್ ಡಂಕನ್ವಿಲ್ಲೆ ಪ್ರೌಢಶಾಲೆಡ್ದ್ ಪದವಿ ಪಡೆಯೆರ್,[೪] ಅಲ್ಪ ಆರ್ ಟ್ರ್ಯಾಕ್ ತಂಡೊಡು ಇತ್ತೆರ್, ನ್ಯಾಷನಲ್ ಆನರ್ ಸೊಸೈಟಿಡ್ ಬೊಕ್ಕ "ಯಶಸ್ವಿ ಆಯೆರೆ ಸಾಧ್ಯತೆ ಉಂಡು" ಪಂಡ್ದ್ ಮತ ಚಲಾಯಿಸಯೆರ್.<ref>[https://web.archive.org/web/20110520201915/http://www.votesmart.org/bio.php?can_id=MTX98792%3Fq%3Dprint vote-smart.org.] {{webarchive|url=https://web.archive.org/web/20081023213318/http://www.vote-smart.org/bio.php?can_id=MTX98792%3Fq%3Dprint |date=October 23, 2008 }}</ref><ref name="WashPostReid10302014">{{cite news |last=Wilson |first=Reid |date=October 30, 2014 |url=https://www.washingtonpost.com/blogs/govbeat/wp/2014/10/30/the-likely-next-governor-of-texas-is-full-of-lone-star-swagger-dont-be-surprised-if-he-runs-for-president/ |newspaper=[[The Washington Post]] |location=Washington, D.C. |access-date=October 31, 2014 |archive-url=https://web.archive.org/web/20141031141816/https://www.washingtonpost.com/blogs/govbeat/wp/2014/10/30/the-likely-next-governor-of-texas-is-full-of-lone-star-swagger-dont-be-surprised-if-he-runs-for-president/ |archive-date=October 31, 2014 |url-status=live}}</ref> ೧೯೮೧ಡ್, ಅಬೊಟ್ ಆಸ್ಟಿನ್ ಡ್ ಟೆಕ್ಸಾಸ್ ವಿಶ್ವವಿದ್ಯಾಲಯೊಡ್ದ್ ಹಣಕಾಸುಡು ಬಿಸಿನೆಸ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಷನ್ ಸ್ನಾತಕೋತ್ತರ ಪದವಿನ್ ಪಡೆಯೆರ್, ಅಲ್ಪ ಆರ್ ಡೆಲ್ಟಾ ಟೌ ಡೆಲ್ಟಾ ಫ್ರಾಟರ್ನಿಟಿ ಬೊಕ್ಕ ಯಂಗ್ ರಿಪಬ್ಲಿಕನ್ಸ್ ಕ್ಲಬ್ ದ ಸದಸ್ಯೆರಾದಿತ್ತೆರ್. ಯುಟಿ ಆಸ್ಟಿನ್ ಡ್ ಓದುನಗ ಅರೆನ ಮದಿಮೆ ಆಯಿನ ಸೆಸಿಲಿಯಾ ಫಾಲೆನ್ ನ್ ತೂಯೆರ್.[3] ಅಕುಲು ರಡ್ಡ್ ಜನಲಾ ೧೯೮೧ಡ್ ಮದಿಮೆ ಆಯೆರ್.[೬] ೧೯೮೪ಡ್, ವಾಂಡರ್ಬಿಲ್ಟ್ ವಿಶ್ವವಿದ್ಯಾಲಯದ ಕಾನೂನು ಶಾಲೆಡ್ದ್ ಜುರಿಸ್ ಡಾಕ್ಟರ್ ಪದವಿನ್ ಗಳಸುವೆರ್. hnspyv5nimms96ix7a7e8vzls2fvq3q ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ 0 27496 362718 2026-07-12T16:19:00Z Mahaveer Indra 1023 ಪೊಸ ಬರವು 362718 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ==ಪರದೇಸೊಡು ಶಾಕೆಲು== ==ಸ್ವಾದೀನೊಲು== == ಉಲ್ಲೇಕ== {{reflist}} byps5pin3v55mo1loj1mdh4n2bistl1 362719 362718 2026-07-12T16:33:43Z Mahaveer Indra 1023 /* ಇತಿಹಾಸೊ */ 362719 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್. ==ಪರದೇಸೊಡು ಶಾಕೆಲು== ==ಸ್ವಾದೀನೊಲು== == ಉಲ್ಲೇಕ== {{reflist}} 6vxcxlems0du7xfbzfatv2z1sdn24ms 362720 362719 2026-07-12T16:34:36Z Mahaveer Indra 1023 /* ಇತಿಹಾಸೊ */ 362720 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== ==ಸ್ವಾದೀನೊಲು== == ಉಲ್ಲೇಕ== {{reflist}} hpa2rgz0ysondnxxy5lm6ov3mxhkpd9 362721 362720 2026-07-12T17:03:16Z Mahaveer Indra 1023 /* ಪರದೇಸೊಡು ಶಾಕೆಲು */ 362721 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== == ಉಲ್ಲೇಕ== {{reflist}} 378iee2m0d8yw6r4tfuspg4oz074yhr 362722 362721 2026-07-12T17:21:40Z Mahaveer Indra 1023 /* ಸ್ವಾದೀನೊಲು */ 362722 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== * ಕೊಯಮತ್ತೂರು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಂಕ್ (1963): ಈ ಬ್ಯಾಂಕ್‌ನ್ 1963 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಐಡ್ದ್ ಬೊಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಇತ್ತಿನ ಒಂಜಿ ಶಾಕೆ ಐಒಬಿದ ಕೈಕ್ ಬತ್ತ್ಂಡ್. * ನಂಜಿನಾಡ್ ಬ್ಯಾಂಕ್: ಈ ಸ್ಥಳೀಯ ಬ್ಯಾಂಕ್‌ನ್ ವಿಲೀನ ಮಲ್ತೆರ್. *ಕೊಯಮತ್ತೂರು ವಸುಂಧರಾ ಬ್ಯಾಂಕ್ (1964): ಜೂನ್ 1924 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಟ್ ಒಂಜಿ ಪ್ರಧಾನ ಕಚೇರಿ ಬುಕ್ಕ ಮೂಜಿ ಶಾಕೆಲು ಐಒಬಿಗ್ ತಿಕ್ಕಿಂಡ್. * ಕುಳಿತಲೈ ಬ್ಯಾಂಕ್ (1964):** 1933 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ಒಟ್ಟು ಆಜಿ ಶಾಕೆಲ್ ಇತ್ತ. * ಶ್ರೀನಿವಾಸ ಪೆರುಮಾಳ್ ಬ್ಯಾಂಕ್ (1966): ಕೊಯಮತ್ತೂರುಡು ನವೆಂಬರ್ 1935 ಡ್ ಆದಿತ್ತಿನ ಇತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1966 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. * ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್ (1967): ಜೂನ್ 1931 ಡ್ 'ಸೇಲಂ ಶೇವಪೇಟ್ ಶ್ರೀ ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಉಂದೆನ್ 1967 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ತಮಿಳುನಾಡ್‌ದ ಸೇಲಂಡು ರಡ್ಡ್ ಶಾಕೆಲು ಇತ್ತ. * ಭಾರತ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ (2007): ದುಂಬು ಬ್ಯಾಂಕಾಕ್‌ದ ಶಾಕೆನ್ ತೂವೊನಿಯೆರೆಗಾದ್ ಸುರು ಮಲ್ತಿತ್ತಿನ ಈ ಖಾಸಗಿ ಬ್ಯಾಂಕ್‌ನ್ 2007 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತೊಂಡ್. * ಬ್ಯಾಂಕ್ ಆಫ್ ತಮಿಳುನಾಡು (1988–89): 1903 ಡ್ ತಿರುನೆಲ್ವೇಲಿಡು 'ಸೌತ್ ಇಂಡಿಯಾ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ ದುಡ್ಡುದ ತೊಂದರೆರ್ದು ರಕ್ಷಣೆ ಮಲ್ಪೆರೆಗಾದ್ 1988–89 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತ್ಂಡ್. ಐತ 99 ಶಾಕೆಲು ಐಒಬಿಗ್ ಸೇರ್ಂಡ್. * ಆದರ್ಶ ಜನತಾ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2001): ಮುಂಬೈ ಮೂಲದ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2001 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್, ಈ ಬ್ಯಾಂಕ್‌ದ ಮುಂಬೈದ ಒಂಜಿ ಶಾಕೆ ತಿಕ್ಕಂಡ್. * ಶ್ರೀ ಸುವರ್ಣ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2009): 1969 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2009 ಡ್ ಐಒಬಿ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕುದ ಪುಣೆಡ್ 9 ಶಾಕೆಲು, ಮುಂಬೈಡ್ 2 ಬುಕ್ಕ ಶ್ರೀಪುರಡ್ 1 ಶಾಕೆ ಬುಕ್ಕ 100ಡ್ದ್ ಎಚ್ಚ ಉದ್ಯೋಗಿಲು ಐಒಬಿಗ್ ಸೇರಿಯೆರ್.<ref>{{cite web |title=Integrated Annual Report 2025-26 |url=https://www.iob.bank.in/documents/d/guest/BSE_NSE_Annual_Report_2025_26 |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> == ಉಲ್ಲೇಕ== {{reflist}} glji69trckf5ad9ikntugm6ubkcm3ve 362724 362722 2026-07-12T17:24:54Z Mahaveer Indra 1023 added [[Category:ಬ್ಯಾ]] using [[Help:Gadget-HotCat|HotCat]] 362724 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== * ಕೊಯಮತ್ತೂರು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಂಕ್ (1963): ಈ ಬ್ಯಾಂಕ್‌ನ್ 1963 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಐಡ್ದ್ ಬೊಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಇತ್ತಿನ ಒಂಜಿ ಶಾಕೆ ಐಒಬಿದ ಕೈಕ್ ಬತ್ತ್ಂಡ್. * ನಂಜಿನಾಡ್ ಬ್ಯಾಂಕ್: ಈ ಸ್ಥಳೀಯ ಬ್ಯಾಂಕ್‌ನ್ ವಿಲೀನ ಮಲ್ತೆರ್. *ಕೊಯಮತ್ತೂರು ವಸುಂಧರಾ ಬ್ಯಾಂಕ್ (1964): ಜೂನ್ 1924 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಟ್ ಒಂಜಿ ಪ್ರಧಾನ ಕಚೇರಿ ಬುಕ್ಕ ಮೂಜಿ ಶಾಕೆಲು ಐಒಬಿಗ್ ತಿಕ್ಕಿಂಡ್. * ಕುಳಿತಲೈ ಬ್ಯಾಂಕ್ (1964):** 1933 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ಒಟ್ಟು ಆಜಿ ಶಾಕೆಲ್ ಇತ್ತ. * ಶ್ರೀನಿವಾಸ ಪೆರುಮಾಳ್ ಬ್ಯಾಂಕ್ (1966): ಕೊಯಮತ್ತೂರುಡು ನವೆಂಬರ್ 1935 ಡ್ ಆದಿತ್ತಿನ ಇತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1966 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. * ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್ (1967): ಜೂನ್ 1931 ಡ್ 'ಸೇಲಂ ಶೇವಪೇಟ್ ಶ್ರೀ ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಉಂದೆನ್ 1967 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ತಮಿಳುನಾಡ್‌ದ ಸೇಲಂಡು ರಡ್ಡ್ ಶಾಕೆಲು ಇತ್ತ. * ಭಾರತ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ (2007): ದುಂಬು ಬ್ಯಾಂಕಾಕ್‌ದ ಶಾಕೆನ್ ತೂವೊನಿಯೆರೆಗಾದ್ ಸುರು ಮಲ್ತಿತ್ತಿನ ಈ ಖಾಸಗಿ ಬ್ಯಾಂಕ್‌ನ್ 2007 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತೊಂಡ್. * ಬ್ಯಾಂಕ್ ಆಫ್ ತಮಿಳುನಾಡು (1988–89): 1903 ಡ್ ತಿರುನೆಲ್ವೇಲಿಡು 'ಸೌತ್ ಇಂಡಿಯಾ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ ದುಡ್ಡುದ ತೊಂದರೆರ್ದು ರಕ್ಷಣೆ ಮಲ್ಪೆರೆಗಾದ್ 1988–89 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತ್ಂಡ್. ಐತ 99 ಶಾಕೆಲು ಐಒಬಿಗ್ ಸೇರ್ಂಡ್. * ಆದರ್ಶ ಜನತಾ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2001): ಮುಂಬೈ ಮೂಲದ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2001 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್, ಈ ಬ್ಯಾಂಕ್‌ದ ಮುಂಬೈದ ಒಂಜಿ ಶಾಕೆ ತಿಕ್ಕಂಡ್. * ಶ್ರೀ ಸುವರ್ಣ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2009): 1969 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2009 ಡ್ ಐಒಬಿ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕುದ ಪುಣೆಡ್ 9 ಶಾಕೆಲು, ಮುಂಬೈಡ್ 2 ಬುಕ್ಕ ಶ್ರೀಪುರಡ್ 1 ಶಾಕೆ ಬುಕ್ಕ 100ಡ್ದ್ ಎಚ್ಚ ಉದ್ಯೋಗಿಲು ಐಒಬಿಗ್ ಸೇರಿಯೆರ್.<ref>{{cite web |title=Integrated Annual Report 2025-26 |url=https://www.iob.bank.in/documents/d/guest/BSE_NSE_Annual_Report_2025_26 |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> == ಉಲ್ಲೇಕ== {{reflist}} [[ವರ್ಗೊ:ಬ್ಯಾ]] aio0ik6g6jz6ubjqpuhfj5o6cha4yxa 362725 362724 2026-07-12T17:25:27Z Mahaveer Indra 1023 removed [[Category:ಬ್ಯಾ]] using [[Help:Gadget-HotCat|HotCat]] 362725 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== * ಕೊಯಮತ್ತೂರು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಂಕ್ (1963): ಈ ಬ್ಯಾಂಕ್‌ನ್ 1963 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಐಡ್ದ್ ಬೊಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಇತ್ತಿನ ಒಂಜಿ ಶಾಕೆ ಐಒಬಿದ ಕೈಕ್ ಬತ್ತ್ಂಡ್. * ನಂಜಿನಾಡ್ ಬ್ಯಾಂಕ್: ಈ ಸ್ಥಳೀಯ ಬ್ಯಾಂಕ್‌ನ್ ವಿಲೀನ ಮಲ್ತೆರ್. *ಕೊಯಮತ್ತೂರು ವಸುಂಧರಾ ಬ್ಯಾಂಕ್ (1964): ಜೂನ್ 1924 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಟ್ ಒಂಜಿ ಪ್ರಧಾನ ಕಚೇರಿ ಬುಕ್ಕ ಮೂಜಿ ಶಾಕೆಲು ಐಒಬಿಗ್ ತಿಕ್ಕಿಂಡ್. * ಕುಳಿತಲೈ ಬ್ಯಾಂಕ್ (1964):** 1933 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ಒಟ್ಟು ಆಜಿ ಶಾಕೆಲ್ ಇತ್ತ. * ಶ್ರೀನಿವಾಸ ಪೆರುಮಾಳ್ ಬ್ಯಾಂಕ್ (1966): ಕೊಯಮತ್ತೂರುಡು ನವೆಂಬರ್ 1935 ಡ್ ಆದಿತ್ತಿನ ಇತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1966 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. * ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್ (1967): ಜೂನ್ 1931 ಡ್ 'ಸೇಲಂ ಶೇವಪೇಟ್ ಶ್ರೀ ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಉಂದೆನ್ 1967 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ತಮಿಳುನಾಡ್‌ದ ಸೇಲಂಡು ರಡ್ಡ್ ಶಾಕೆಲು ಇತ್ತ. * ಭಾರತ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ (2007): ದುಂಬು ಬ್ಯಾಂಕಾಕ್‌ದ ಶಾಕೆನ್ ತೂವೊನಿಯೆರೆಗಾದ್ ಸುರು ಮಲ್ತಿತ್ತಿನ ಈ ಖಾಸಗಿ ಬ್ಯಾಂಕ್‌ನ್ 2007 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತೊಂಡ್. * ಬ್ಯಾಂಕ್ ಆಫ್ ತಮಿಳುನಾಡು (1988–89): 1903 ಡ್ ತಿರುನೆಲ್ವೇಲಿಡು 'ಸೌತ್ ಇಂಡಿಯಾ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ ದುಡ್ಡುದ ತೊಂದರೆರ್ದು ರಕ್ಷಣೆ ಮಲ್ಪೆರೆಗಾದ್ 1988–89 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತ್ಂಡ್. ಐತ 99 ಶಾಕೆಲು ಐಒಬಿಗ್ ಸೇರ್ಂಡ್. * ಆದರ್ಶ ಜನತಾ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2001): ಮುಂಬೈ ಮೂಲದ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2001 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್, ಈ ಬ್ಯಾಂಕ್‌ದ ಮುಂಬೈದ ಒಂಜಿ ಶಾಕೆ ತಿಕ್ಕಂಡ್. * ಶ್ರೀ ಸುವರ್ಣ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2009): 1969 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2009 ಡ್ ಐಒಬಿ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕುದ ಪುಣೆಡ್ 9 ಶಾಕೆಲು, ಮುಂಬೈಡ್ 2 ಬುಕ್ಕ ಶ್ರೀಪುರಡ್ 1 ಶಾಕೆ ಬುಕ್ಕ 100ಡ್ದ್ ಎಚ್ಚ ಉದ್ಯೋಗಿಲು ಐಒಬಿಗ್ ಸೇರಿಯೆರ್.<ref>{{cite web |title=Integrated Annual Report 2025-26 |url=https://www.iob.bank.in/documents/d/guest/BSE_NSE_Annual_Report_2025_26 |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> == ಉಲ್ಲೇಕ== {{reflist}} glji69trckf5ad9ikntugm6ubkcm3ve 362726 362725 2026-07-12T17:25:39Z Mahaveer Indra 1023 added [[Category:ಬ್ಯಾಂಕುಲು]] using [[Help:Gadget-HotCat|HotCat]] 362726 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== * ಕೊಯಮತ್ತೂರು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಂಕ್ (1963): ಈ ಬ್ಯಾಂಕ್‌ನ್ 1963 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಐಡ್ದ್ ಬೊಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಇತ್ತಿನ ಒಂಜಿ ಶಾಕೆ ಐಒಬಿದ ಕೈಕ್ ಬತ್ತ್ಂಡ್. * ನಂಜಿನಾಡ್ ಬ್ಯಾಂಕ್: ಈ ಸ್ಥಳೀಯ ಬ್ಯಾಂಕ್‌ನ್ ವಿಲೀನ ಮಲ್ತೆರ್. *ಕೊಯಮತ್ತೂರು ವಸುಂಧರಾ ಬ್ಯಾಂಕ್ (1964): ಜೂನ್ 1924 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಟ್ ಒಂಜಿ ಪ್ರಧಾನ ಕಚೇರಿ ಬುಕ್ಕ ಮೂಜಿ ಶಾಕೆಲು ಐಒಬಿಗ್ ತಿಕ್ಕಿಂಡ್. * ಕುಳಿತಲೈ ಬ್ಯಾಂಕ್ (1964):** 1933 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ಒಟ್ಟು ಆಜಿ ಶಾಕೆಲ್ ಇತ್ತ. * ಶ್ರೀನಿವಾಸ ಪೆರುಮಾಳ್ ಬ್ಯಾಂಕ್ (1966): ಕೊಯಮತ್ತೂರುಡು ನವೆಂಬರ್ 1935 ಡ್ ಆದಿತ್ತಿನ ಇತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1966 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. * ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್ (1967): ಜೂನ್ 1931 ಡ್ 'ಸೇಲಂ ಶೇವಪೇಟ್ ಶ್ರೀ ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಉಂದೆನ್ 1967 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ತಮಿಳುನಾಡ್‌ದ ಸೇಲಂಡು ರಡ್ಡ್ ಶಾಕೆಲು ಇತ್ತ. * ಭಾರತ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ (2007): ದುಂಬು ಬ್ಯಾಂಕಾಕ್‌ದ ಶಾಕೆನ್ ತೂವೊನಿಯೆರೆಗಾದ್ ಸುರು ಮಲ್ತಿತ್ತಿನ ಈ ಖಾಸಗಿ ಬ್ಯಾಂಕ್‌ನ್ 2007 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತೊಂಡ್. * ಬ್ಯಾಂಕ್ ಆಫ್ ತಮಿಳುನಾಡು (1988–89): 1903 ಡ್ ತಿರುನೆಲ್ವೇಲಿಡು 'ಸೌತ್ ಇಂಡಿಯಾ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ ದುಡ್ಡುದ ತೊಂದರೆರ್ದು ರಕ್ಷಣೆ ಮಲ್ಪೆರೆಗಾದ್ 1988–89 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತ್ಂಡ್. ಐತ 99 ಶಾಕೆಲು ಐಒಬಿಗ್ ಸೇರ್ಂಡ್. * ಆದರ್ಶ ಜನತಾ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2001): ಮುಂಬೈ ಮೂಲದ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2001 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್, ಈ ಬ್ಯಾಂಕ್‌ದ ಮುಂಬೈದ ಒಂಜಿ ಶಾಕೆ ತಿಕ್ಕಂಡ್. * ಶ್ರೀ ಸುವರ್ಣ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2009): 1969 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2009 ಡ್ ಐಒಬಿ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕುದ ಪುಣೆಡ್ 9 ಶಾಕೆಲು, ಮುಂಬೈಡ್ 2 ಬುಕ್ಕ ಶ್ರೀಪುರಡ್ 1 ಶಾಕೆ ಬುಕ್ಕ 100ಡ್ದ್ ಎಚ್ಚ ಉದ್ಯೋಗಿಲು ಐಒಬಿಗ್ ಸೇರಿಯೆರ್.<ref>{{cite web |title=Integrated Annual Report 2025-26 |url=https://www.iob.bank.in/documents/d/guest/BSE_NSE_Annual_Report_2025_26 |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> == ಉಲ್ಲೇಕ== {{reflist}} [[ವರ್ಗೊ:ಬ್ಯಾಂಕುಲು]] 1wqclizzta4m1l0gxyiuh8xk0d38u5a 362727 362726 2026-07-12T17:25:56Z Mahaveer Indra 1023 added [[Category:ಭಾರತೊದ ಸಾರ್ವಜನಿಕ ರಂಗದ ಬ್ಯಾಂಕುಲು]] using [[Help:Gadget-HotCat|HotCat]] 362727 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== * ಕೊಯಮತ್ತೂರು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಂಕ್ (1963): ಈ ಬ್ಯಾಂಕ್‌ನ್ 1963 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಐಡ್ದ್ ಬೊಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಇತ್ತಿನ ಒಂಜಿ ಶಾಕೆ ಐಒಬಿದ ಕೈಕ್ ಬತ್ತ್ಂಡ್. * ನಂಜಿನಾಡ್ ಬ್ಯಾಂಕ್: ಈ ಸ್ಥಳೀಯ ಬ್ಯಾಂಕ್‌ನ್ ವಿಲೀನ ಮಲ್ತೆರ್. *ಕೊಯಮತ್ತೂರು ವಸುಂಧರಾ ಬ್ಯಾಂಕ್ (1964): ಜೂನ್ 1924 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಟ್ ಒಂಜಿ ಪ್ರಧಾನ ಕಚೇರಿ ಬುಕ್ಕ ಮೂಜಿ ಶಾಕೆಲು ಐಒಬಿಗ್ ತಿಕ್ಕಿಂಡ್. * ಕುಳಿತಲೈ ಬ್ಯಾಂಕ್ (1964):** 1933 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ಒಟ್ಟು ಆಜಿ ಶಾಕೆಲ್ ಇತ್ತ. * ಶ್ರೀನಿವಾಸ ಪೆರುಮಾಳ್ ಬ್ಯಾಂಕ್ (1966): ಕೊಯಮತ್ತೂರುಡು ನವೆಂಬರ್ 1935 ಡ್ ಆದಿತ್ತಿನ ಇತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1966 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. * ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್ (1967): ಜೂನ್ 1931 ಡ್ 'ಸೇಲಂ ಶೇವಪೇಟ್ ಶ್ರೀ ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಉಂದೆನ್ 1967 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ತಮಿಳುನಾಡ್‌ದ ಸೇಲಂಡು ರಡ್ಡ್ ಶಾಕೆಲು ಇತ್ತ. * ಭಾರತ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ (2007): ದುಂಬು ಬ್ಯಾಂಕಾಕ್‌ದ ಶಾಕೆನ್ ತೂವೊನಿಯೆರೆಗಾದ್ ಸುರು ಮಲ್ತಿತ್ತಿನ ಈ ಖಾಸಗಿ ಬ್ಯಾಂಕ್‌ನ್ 2007 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತೊಂಡ್. * ಬ್ಯಾಂಕ್ ಆಫ್ ತಮಿಳುನಾಡು (1988–89): 1903 ಡ್ ತಿರುನೆಲ್ವೇಲಿಡು 'ಸೌತ್ ಇಂಡಿಯಾ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ ದುಡ್ಡುದ ತೊಂದರೆರ್ದು ರಕ್ಷಣೆ ಮಲ್ಪೆರೆಗಾದ್ 1988–89 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತ್ಂಡ್. ಐತ 99 ಶಾಕೆಲು ಐಒಬಿಗ್ ಸೇರ್ಂಡ್. * ಆದರ್ಶ ಜನತಾ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2001): ಮುಂಬೈ ಮೂಲದ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2001 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್, ಈ ಬ್ಯಾಂಕ್‌ದ ಮುಂಬೈದ ಒಂಜಿ ಶಾಕೆ ತಿಕ್ಕಂಡ್. * ಶ್ರೀ ಸುವರ್ಣ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2009): 1969 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2009 ಡ್ ಐಒಬಿ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕುದ ಪುಣೆಡ್ 9 ಶಾಕೆಲು, ಮುಂಬೈಡ್ 2 ಬುಕ್ಕ ಶ್ರೀಪುರಡ್ 1 ಶಾಕೆ ಬುಕ್ಕ 100ಡ್ದ್ ಎಚ್ಚ ಉದ್ಯೋಗಿಲು ಐಒಬಿಗ್ ಸೇರಿಯೆರ್.<ref>{{cite web |title=Integrated Annual Report 2025-26 |url=https://www.iob.bank.in/documents/d/guest/BSE_NSE_Annual_Report_2025_26 |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> == ಉಲ್ಲೇಕ== {{reflist}} [[ವರ್ಗೊ:ಬ್ಯಾಂಕುಲು]] [[ವರ್ಗೊ:ಭಾರತೊದ ಸಾರ್ವಜನಿಕ ರಂಗದ ಬ್ಯಾಂಕುಲು]] jccbr8q9n3nbmj4ww2aoo0j4149afjt 362728 362727 2026-07-12T17:26:26Z Mahaveer Indra 1023 added [[Category:ತುಳು ವಿಕಿಪೀಡಿಯ 10ನೇ ವರ್ಸಾಂತ್ಯೊ]] using [[Help:Gadget-HotCat|HotCat]] 362728 wikitext text/x-wiki '''ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್''' (ಎಲ್ಯೊಡು-'''ಐಒಬಿ''') ನಮ ದೇಸೊದ ಸಾರ್ವಜನಿಕ ವಲಯದ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಇಂದೆನ್ ೧೯೩೭ನೇ ಇಸವಿಡ್ ಉಂಡುಮಲ್ತೆರ್. ಇಂದೆತ ಮುಖ್ಯ ಕಛೇರಿ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಚೆನ್ನೈಡ್ ಉಂಡು. ಮಾರ್ಚಿ ೨೦೨೬ದ ವರದಿದ ಲೆಕ್ಕೊಡು ಐಒಬಿಗ್ ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೪೯೪ ಶಾಕೆಲು ಉಲ್ಲ. ಅಂಚನೆ ಪರದೇಸೊಡು ೪ ಶಾಕೆಲು ಉಲ್ಲ. ದೇಸೊರ್ಮೆ ಒಟ್ಟು ೩೬೫೧ ಎಟಿಎಮ್‌ಲು ಉಲ್ಲ.<ref>{{cite web |title=Performance Analysis For Quarter / Year Ended 31st March 2026 |url=https://www.iob.bank.in/documents/d/guest/IOB_Analyst_Presentation_31032026 |website=iob.bank.in |access-date=12 July 2026}}</ref> ಮಾರುಕಟ್ಟೆ ಬಂಡವಾಳೊನು ಲೆಕ್ಕ ಪತ್ತಿಂಡ, ಸಾರ್ವಜನಿಕ ವಲಯೊದ ಬ್ಯಾಂಕ್‌ಲೆಡ್ ಐಒಬಿ ೭ನೇ ಸಾನೊಡು ಉಂಡು. ==ಇತಿಹಾಸೊ== ಪುದರ್‌ಡ್ ಇತ್ತಿಲೆಕ, ಈ ಬ್ಯಾಂಕ್ ಪರದೇಸೊಡು ವ್ಯವಹಾರ ಬುಕ್ಕ ವಿದೇಶಿ ಪಣವು ಬದಲಾವಣೆದ ವ್ಯವಹಾರ ಮಲ್ಪರಗಾತ್ರ ಉಂಡು ಮಲ್ತಿನ ಒಂಜಿ ಬ್ಯಾಂಕ್. ಈ ಬ್ಯಾಂಕುನ್ ೧೯೩೭ನೇ ಇಸವಿದ ಫೆಬ್ರವರಿಡ್ ಎಂ ಎಂ ಚಿದಂಬರಮ್ ಚೆಟ್ಟಿಯಾರ್ ಇನ್ಪಿನ ತಮಿಳುನಾಡುದ ಒರಿ ಕೈಗಾರಿಕೋದ್ಯಮಿ ಸ್ತಾಪಿಸಾಯೆರ್.<ref>{{cite web |title=About us |url=https://www.iob.bank.in/en/about-us |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> ==ಪರದೇಸೊಡು ಶಾಕೆಲು== 1937 ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಸುರು ಆನಗ ತಮಿಳುನಾಡು ರಾಜ್ಯೊದ ಕಾರೈಕುಡಿ ಬುಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಬುಕ್ಕೊ ರಂಗೂನ್ (ರಂಗೂನ್ ಮಯನ್ಮಾರ್ ದೇಸೊಡು ಉಂಡು)ಡು ಶಾಕೆಲೆನ್ ಸುರು ಮಲ್ತೆರ್. 1938 ಡ್ ಮಲೇಷ್ಯಾ ದೇಸೊದ ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಕೌಲಾಲಂಪುರಡ್ ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸಿಂಗಾಪುರ ದೇಸೊಡು 1941 ಡ್ ವರ್ಷೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. ಸುರುತ ಇಸ್ವಯುದ್ದಡ್ದಾತ್ರ ರಂಗೂನ್, ಪೆನಾಂಗ್ ಬುಕ್ಕೊ ಸಿಂಗಾಪುರಡ್ ಇತ್ತಿನ ಶಾಕೆಲು ಮುಚ್ಚೊಡಾಂಡ್. ಆಂಡ, 1942 ಡ್ ಸಿಂಗಾಪುರನ್ ಜಪಾನ್ ದೇಸೊ ಆಕ್ರಮಿಸಾಯಿ ಬುಕ್ಕ ಜಪಾನ್ ದೇಸೊದ ಮೇಲ್ವಿಚಾರಣೆಡ್ ಸಿಂಗಾಪುರತ್ತ ಶಾಕೆ ಕುಡ ಸುರು ಆಂಡ್. ೧೯೪೫ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ಒಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1947ನೇ ಇಸವಿಡ್‌ ಥೈಲ್ಯಾಂಡ್‌ದ ಬ್ಯಾಂಕಾಕ್‌ಡ್ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂದಾಜಿ ಅವ್ವೆ ವರ್ಸೊಡು ಮಲೇಷ್ಯಾ ದೇಸೊದ ಇಪೋ, ಕ್ಲಾಂಗ್ ಬುಕ್ಕೊ ಮಲಕ್ಕಾ ಪುದರ್‌ದ ಊರುಡು ಒಂಜೊಂಜಿ ಶಾಕೆನ್ ಸುರು ಮಲ್ತೆರ್. 1955ನೇ ಇಸವಿಡ್‌ ಹಾಂಗ್ ಕಾಂಗ್‌ಡ್ ಬ್ಯಾಂಕ್ ತನ್ನ ಸುರುತ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. 1977ನೇ ಇಸವಿಡ್‌ ದಕ್ಷಿಣ ಕೊರಿಯಾದ ಸಿಯೋಲ್‌ಡ್ ಐಒಬಿ ಪೊಸ ಶಾಕೆನ್ ಸುರು ಮಲ್ತ್ಂಡ್. ಅಂಚನೆ ಹಾಂಗ್ ಕಾಂಗ್‌‌ದ ಕೌಲೂನ್‌‍ಡು ಬೊಕ್ಕೊಂಜಿ ಶಾಕೆ ಸುರು ಆಂಡ್. 1979ನೇ ಇಸವಿಡ್‌ ಶ್ರೀಲಂಕಾದ ಕೊಲಂಬೊಡು ವಿದೇಶಿ ಕರೆನ್ಸಿ ಬ್ಯಾಂಕಿಂಗ್ ಘಟಕೊನು ಸುರು ಮಲ್ತೆರ್. 2005ನೇ ಇಸವಿಡ್‌ ಚೀನಾದ ಗುವಾಂಗ್‌ಝೌ ಪನ್ಪಿನಲ್ಪ, 2006ಡ್‌ ಮಲೇಷ್ಯಾದ ಕೌಲಾಲಂಪುರ್ಡ್ ಬುಕ್ಕ ೨೦೦೯ಡು ದುಬೈಡ್ ಪ್ರತಿನಿಧಿ ಕಚೇರಿನ್ ಸುರು ಮಲ್ತೆರ್. 2012ನೇ ಇಸವಿಡ್ ಬ್ಯಾಂಕ್ ಆಫ್ ಬರೋಡಾ ಬುಕ್ಕೊ ಆಂಧ್ರ ಬ್ಯಾಂಕ್ ಭಾಗಿತ್ವೊಡು ಜಂಟಿ ಉದ್ಯಮವಾದ್ ಸುರು ಆಯಿನ 'ಇಂಡಿಯಾ ಇಂಟರ್ನ್ಯಾಷನಲ್ ಬ್ಯಾಂಕ್ (ಮಲೇಷ್ಯಾ)' ಕೌಲಾಲಂಪುರಟ್ಟ್ ತನ್ನೊ ಬ್ಯಾಂಕಿಂಗ್ ಕೆಲಸೊನು ಸುರು ಮಲ್ತ್ಂಡ್.<ref>{{cite web |title=Genesis |url=https://www.iob.bank.in/en/genesis |website=iob.bank.in |access-date=12 July 2026}}</ref> ==ಸ್ವಾದೀನೊಲು== * ಕೊಯಮತ್ತೂರು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಬ್ಯಾಂಕ್ (1963): ಈ ಬ್ಯಾಂಕ್‌ನ್ 1963 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಐಡ್ದ್ ಬೊಕ್ಕ ಮದ್ರಾಸ್‌ಡ್ ಇತ್ತಿನ ಒಂಜಿ ಶಾಕೆ ಐಒಬಿದ ಕೈಕ್ ಬತ್ತ್ಂಡ್. * ನಂಜಿನಾಡ್ ಬ್ಯಾಂಕ್: ಈ ಸ್ಥಳೀಯ ಬ್ಯಾಂಕ್‌ನ್ ವಿಲೀನ ಮಲ್ತೆರ್. *ಕೊಯಮತ್ತೂರು ವಸುಂಧರಾ ಬ್ಯಾಂಕ್ (1964): ಜೂನ್ 1924 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಟ್ ಒಂಜಿ ಪ್ರಧಾನ ಕಚೇರಿ ಬುಕ್ಕ ಮೂಜಿ ಶಾಕೆಲು ಐಒಬಿಗ್ ತಿಕ್ಕಿಂಡ್. * ಕುಳಿತಲೈ ಬ್ಯಾಂಕ್ (1964):** 1933 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1964 ಡ್ ಸ್ವಾದೀನೊ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ಒಟ್ಟು ಆಜಿ ಶಾಕೆಲ್ ಇತ್ತ. * ಶ್ರೀನಿವಾಸ ಪೆರುಮಾಳ್ ಬ್ಯಾಂಕ್ (1966): ಕೊಯಮತ್ತೂರುಡು ನವೆಂಬರ್ 1935 ಡ್ ಆದಿತ್ತಿನ ಇತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 1966 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. * ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್ (1967): ಜೂನ್ 1931 ಡ್ 'ಸೇಲಂ ಶೇವಪೇಟ್ ಶ್ರೀ ವೆಂಕಟೇಶ್ವರ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಉಂದೆನ್ 1967 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್. ಉಂದೆಕ್ ತಮಿಳುನಾಡ್‌ದ ಸೇಲಂಡು ರಡ್ಡ್ ಶಾಕೆಲು ಇತ್ತ. * ಭಾರತ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ (2007): ದುಂಬು ಬ್ಯಾಂಕಾಕ್‌ದ ಶಾಕೆನ್ ತೂವೊನಿಯೆರೆಗಾದ್ ಸುರು ಮಲ್ತಿತ್ತಿನ ಈ ಖಾಸಗಿ ಬ್ಯಾಂಕ್‌ನ್ 2007 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತೊಂಡ್. * ಬ್ಯಾಂಕ್ ಆಫ್ ತಮಿಳುನಾಡು (1988–89): 1903 ಡ್ ತಿರುನೆಲ್ವೇಲಿಡು 'ಸೌತ್ ಇಂಡಿಯಾ ಬ್ಯಾಂಕ್' ಆದ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ ದುಡ್ಡುದ ತೊಂದರೆರ್ದು ರಕ್ಷಣೆ ಮಲ್ಪೆರೆಗಾದ್ 1988–89 ಡ್ ಐಒಬಿ ಸ್ವಾದೀನ ಮಲ್ತ್ಂಡ್. ಐತ 99 ಶಾಕೆಲು ಐಒಬಿಗ್ ಸೇರ್ಂಡ್. * ಆದರ್ಶ ಜನತಾ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2001): ಮುಂಬೈ ಮೂಲದ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2001 ಡ್ ಸ್ವಾದೀನ ಮಲ್ತೆರ್, ಈ ಬ್ಯಾಂಕ್‌ದ ಮುಂಬೈದ ಒಂಜಿ ಶಾಕೆ ತಿಕ್ಕಂಡ್. * ಶ್ರೀ ಸುವರ್ಣ ಸಹಕಾರಿ ಬ್ಯಾಂಕ್ (2009): 1969 ಡ್ ಸುರು ಆದಿತ್ತಿನ ಈ ಬ್ಯಾಂಕ್‌ನ್ 2009 ಡ್ ಐಒಬಿ ದೆತೊಂಡು. ಈ ಬ್ಯಾಂಕುದ ಪುಣೆಡ್ 9 ಶಾಕೆಲು, ಮುಂಬೈಡ್ 2 ಬುಕ್ಕ ಶ್ರೀಪುರಡ್ 1 ಶಾಕೆ ಬುಕ್ಕ 100ಡ್ದ್ ಎಚ್ಚ ಉದ್ಯೋಗಿಲು ಐಒಬಿಗ್ ಸೇರಿಯೆರ್.<ref>{{cite web |title=Integrated Annual Report 2025-26 |url=https://www.iob.bank.in/documents/d/guest/BSE_NSE_Annual_Report_2025_26 |website=iob.bank.in |publisher=IOB |access-date=12 July 2026}}</ref> == ಉಲ್ಲೇಕ== {{reflist}} [[ವರ್ಗೊ:ಬ್ಯಾಂಕುಲು]] [[ವರ್ಗೊ:ಭಾರತೊದ ಸಾರ್ವಜನಿಕ ರಂಗದ ಬ್ಯಾಂಕುಲು]] [[ವರ್ಗೊ:ತುಳು ವಿಕಿಪೀಡಿಯ 10ನೇ ವರ್ಸಾಂತ್ಯೊ]] j4e5b6q0s9gjnk0vh5lklwmlrxjki7u ಪಾತೆರ:ಇಂಡಿಯನ್ ಓವರ್‌ಸೀಸ್ ಬ್ಯಾಂಕ್ 1 27497 362723 2026-07-12T17:24:11Z Mahaveer Indra 1023 https://fountain.toolforge.org/editathons/10wiki-tcy 362723 wikitext text/x-wiki {{ವಿಕಿಪೀಡಿಯ 10ನೇ ವರ್ಸಂತಿಗೆ ಪಂತೊದ ಲೇಕನೊ}} nekn5axm94un6rhhgr63qit15105phm ದೇವಿಕಾ ನಾಗೇಶ್ 0 27498 362729 2026-07-12T18:41:21Z BENET G AMANNA 60 ಪೊಸ ಲೇಖನ / ವ್ಯಕ್ತಿ ಪರಿಚಯ/ 362729 wikitext text/x-wiki ದೇವಿಕಾ ನಾಗೇಶ್ [[Devika Nagesh]]ಕಥೆಗಾರ್ತಿ, ಕವಯಿತ್ರಿ ==ಪುಟ್ಟು== ಕೆ. ಬೋಜ ಶೆಟ್ಟಿ ಬೊಕ್ಕ ನಳಿನಾ ದಂಪತಿಳೆಗ್ ೬ ಜೋಕುಲು. ೨೯-೫-೧೯೬೨ ದು ಹಾಸನ ಜಿಲ್ಲೆದ ಬೇಲೂರು ತಾಲೂಕುದ ಹಸುರು ಗುಡ್ಡೆ ಪನ್ಪಿ ಜಾಗೆಡ್ ಪುಟ್ಟಿಯೆರ್. == ಬರವು == # ಉಡುಪಿ ಕಿದಿಯೂರು ಶ್ರಿ ವಿದ್ಯಾ ಸಮುದ್ರ ತೀರ್ಥ ಶಾಲೆಡ್ ಪ್ರಾಥಮಿಕ ಬೊಕ್ಕ ಹೈಸ್ಕೂಲು ವಿದ್ಯಾಭ್ಯಾಸ # ಉಡಪಿದ ಪೂರ್ಣ ಪ್ರಜ್ಙ ಕಾಲೇಜ್ಡ್ ಪದವಿ ಪೂರ್ವ ಬೊಕ್ಕ ಪದವಿನ್ ಪಡೆಯೆರ್ ==ಸಂಸಾರ== ಬೇಲೂರು ತಾಲೂಕುದ ಹೊಸಳ್ಳಿಡ್ ಉಪ್ಪುನ ಕಾಪಿ ಎಸ್ಟೇಟ್ ಟ್ ಕುಟುಂಬೊದೊಟ್ಟುಗು ವಾಸ ಮಲ್ತೊಂದಿತ್ತಿ ಮೇರ್ ೧೯೮೯ ಡ್ ಅಲ್ಪನೇ ಕಟ್ಟೋಣ ನಿರ್ಮಾಣ ಕಾಂಟಷರಾಕ್ಟರ್ ಆದಿತ್ತಿ ನಾಗೇಶ್ ಶೆಟ್ರೆನ್ ಮದ್ಮೆ ಆಯಿಬೊಕ್ಕ ಕುಡ್ಲಡ್ ಪೊಸ ಸಂಸಾರೊನು ಆರಂಭ ಮಲ್ತೊಂದು ಒಂಜಿ ಮಗೆ, ಮರ್ಮಲ್ ಪುಲ್ಲಿನ್ ಪಡೆತಿನ ಮೇರ್ ಬೇಲೆದೊಟ್ಟುಗು ಬರೆಪಿನ ಹವ್ಯಾಸೊನ್ಲಾ ಪಡೆತೆರ್. == ಉದ್ಯೋಗ== # ಪೋಸ್ಟಲ್ # ಪ್ರಜ್ಞಾ ಸಲಹಾ ಕೇಂದ್ರ ಮಮಗಲೂರು ೨೦೦೬-೨೦೨೦ == ಸದಸ್ಯೆರಾದ್== ==ಬರವುಲು== ==ಕೃತಿಕ್ಕುಲು== == ಪಡೆಯಿ ಪುಗರ್ತೆಲು== 79d895s579fg4oirrbyo8ek3srzbvss 362730 362729 2026-07-12T18:45:45Z BENET G AMANNA 60 362730 wikitext text/x-wiki ದೇವಿಕಾ ನಾಗೇಶ್ [[Devika Nagesh]]ಕಥೆಗಾರ್ತಿ, ಕವಯಿತ್ರಿ ==ಪುಟ್ಟು== ಕೆ. ಬೋಜ ಶೆಟ್ಟಿ ಬೊಕ್ಕ ನಳಿನಾ ದಂಪತಿಳೆಗ್ ೬ ಜೋಕುಲು. ೨೯-೫-೧೯೬೨ ದು ಹಾಸನ ಜಿಲ್ಲೆದ ಬೇಲೂರು ತಾಲೂಕುದ ಹಸುರು ಗುಡ್ಡೆ ಪನ್ಪಿ ಜಾಗೆಡ್ ಪುಟ್ಟಿಯೆರ್. == ಬರವು == # ಉಡುಪಿ ಕಿದಿಯೂರು ಶ್ರಿ ವಿದ್ಯಾ ಸಮುದ್ರ ತೀರ್ಥ ಶಾಲೆಡ್ ಪ್ರಾಥಮಿಕ ಬೊಕ್ಕ ಹೈಸ್ಕೂಲು ವಿದ್ಯಾಭ್ಯಾಸ # ಉಡಪಿದ ಪೂರ್ಣ ಪ್ರಜ್ಙ ಕಾಲೇಜ್ಡ್ ಪದವಿ ಪೂರ್ವ ಬೊಕ್ಕ ಪದವಿನ್ ಪಡೆಯೆರ್ ==ಸಂಸಾರ== ಬೇಲೂರು ತಾಲೂಕುದ ಹೊಸಳ್ಳಿಡ್ ಉಪ್ಪುನ ಕಾಪಿ ಎಸ್ಟೇಟ್ ಟ್ ಕುಟುಂಬೊದೊಟ್ಟುಗು ವಾಸ ಮಲ್ತೊಂದಿತ್ತಿ ಮೇರ್ ೧೯೮೯ ಡ್ ಅಲ್ಪನೇ ಕಟ್ಟೋಣ ನಿರ್ಮಾಣ ಕಾಂಟಷರಾಕ್ಟರ್ ಆದಿತ್ತಿ ನಾಗೇಶ್ ಶೆಟ್ರೆನ್ ಮದ್ಮೆ ಆಯಿಬೊಕ್ಕ ಕುಡ್ಲಡ್ ಪೊಸ ಸಂಸಾರೊನು ಆರಂಭ ಮಲ್ತೊಂದು ಒಂಜಿ ಮಗೆ, ಮರ್ಮಲ್ ಪುಲ್ಲಿನ್ ಪಡೆತಿನ ಮೇರ್ ಬೇಲೆದೊಟ್ಟುಗು ಬರೆಪಿನ ಹವ್ಯಾಸೊನ್ಲಾ ಪಡೆತೆರ್. == ಉದ್ಯೋಗ== # ಪೋಸ್ಟಲ್ # ಪ್ರಜ್ಞಾ ಸಲಹಾ ಕೇಂದ್ರ ಮಮಗಲೂರು ೨೦೦೬-೨೦೨೦ == ಸದಸ್ಯೆರಾದ್== ==ಬರವುಲು== ==ಕೃತಿಕ್ಕುಲು== == ಪಡೆಯಿ ಪುಗರ್ತೆಲು== http://pustakamane.com/@devika-nagesh?srsltid=AfmBOoqpSIOpqb4Up9yFXwIb6Jd9_U0sDULqi6VDwfg598HoqGQZWmO3 https://www.amazon.in/Kallarali-Hoovagi-Paperback-Devika-Nagesh/dp/B0DXLB153H er6npl80t2xaf4wshrbf7tqdeda50mn